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time are necessary to complete a transaction for a vehicle. 
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AUTOMATIC REAL-TIME fflGHWAY TOLL COLLECTION FROM 

MOVING VEfflCLES 

BACKGIKXJND OFTHE INVENTTQN 

5 

L Field of the Invention 

This invention relates generally to automatic real-time hi^way toll 
collection from moving vehicles. It is especially adapted to the use of an 
untraceable electronic check debited from a smart card and communicated in a 
10 cryptogr^hically sealed envelope with opener. The invention relates directly 
to an in-vehicle unit (TVU) and a roadside collection station (RCS) and to an 
overall system incorporating a plurality of RCS's and TVUs The invention 
may also find use for parking collections and other types of road pricing 
applications.. 

15 

2. Rglated Prior Ait 

The microwave communication and cryptographic processing 
componCTits of this invention are related to the following prior issued U.S. 
Patents which are hereby incorporated herein by reference: 
20 U.S. Patent No, 4,075,632 - Baldwin et al. (1978) 

U.S. Patent No. 4,739,328 - Koelle et al (1988) 

U.S. Patent No. 5,030,807 - Landt et al (1991) 

U.S. Patent No. 5,055,659 - Hendrick et al (1991) 

U.S. Patent No. 4,759,063 - Chaum (1988) 
25 U.S. Patent No. 4,926,480 - Chaum (1990) 

U.S. Patent No. 5,131,039 - Chaum (1992) 

Numerous electronic toll collection systems have been implemented 
during the past several years. In most cases, vehicle readers and their 
30 associated microwave antennas are located at well defined toll plazas and 



SUBSTITUTE SHEET (RULE 26) 



wo 95/10147 PCT/US94/1 1453 



2 

readable tags are lcx:ated on the vehicles. As a tag-equipped vehicle enters the 
read range of the antenna, a fixed code is read out from the tag. The code is 
then conq>ared with an online database to verify the account and determine 
vehicle classification- Next, the user's account is debited by the appropriate 
5 amount and the vehicle is permitted to pass. This system is simple in the 
sense that the amount of data to be handled is typically small and data need 
pass in only one direction (i.e., uplink). These sinplifications can lead to a 
system which may operate with a relatively low data bandwidth and with 
reasonably hi^ vehicle speeds. 

10 

Sometimes the computation of toll charge is based, in part, upon the 
identity of the entry plaza at which the vehicle entered the system. In this 
case, it is necessary to either write the identity of the entry plaza into the tag 
or to communicate the fixed tag code and associated entry plaza over a 
15 network so that each exit plaza in the entire system has online access to the 
fl^ta Needless to say, both of these alternatives complicate the system, 
necessite a hi^er bandwidth, and may prove expensive to inplement. 

Furthermore, some users may object to loss of privacy since the fixed 
20 tag code serves to identify the owner and his or her whereabouts. Low value, 
off-line payment systems which provide privacy to the user are now gaining 
commercial acceptance. These systems often make use of a reusable smart 
card or its predecessor, the disposable memory card, 

25 Automatic real-time toll collection in general has been a long-standing 

goal of many prior efforts. The following U.S. Patents are a few examples of 
prior systems which proport to provide one aspect or another of such systems: 
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U.S. Patent No. 4,303,904 - Chasek (1991) 
U.S. Patent No. 5,086,389 - Hassett et al (1992) 
U.S. Patent No. 5,144,553 - Hassett et al (1992) 

5 As explained by Chasek, conventional, manual toll collection facilities 

slow trafBc, waste time and fuel and increase air pollution. Such manual 
fecilities can also be relatively inefficient in temis of overhead costs required 
for toll collection processes. 

10 Chasek is periiaps typical in prior art approaches to automatic toll 

collection which propose the use of prepaid tolls inserted electronically in the 
memory of a microwave transponder-data-processor, normally kept in the 
vehicle. As the vehicle passes throu^ a suitably equipped toll collection 
facility, a toll plaza microwave transponder receives billing information from 

15 the vehicle transponder, calculates the toll, transmits it back to the vehicle 

transponder where the toll is electronically subtracted from a stored balance. If 
the resulting balance is not negative, a pass signal is then flashed Typical 
information to be stored in the vehicle transponder permanent memory and 
communicated to the toll collection facility would include a vehicle-owner 

20 identity code, a collection agent code and a vehicle-class code. The 

availability of this information permits calculation of the toll. A procedure for 
increasing the pre-paid balance makes possible a computerized and automated 
double entry bookkeeping and fimds transfer system. Security is said to be 
achieved by "crypto-insertion codes". The stored cun^t electronic money 

25 balance in the vehicle transponder is to be indicated by a liquid crystal display. 
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Such automatic toll systems may offer some improvement over other prior 
art techniques employing only automatic vehicle identification (e.g. one-way 
* Hntn communication rather than bi-directional data communication) and 
involving intricate centralized cong^uter facilities for storing and extracting 
5 billing information fi^m potentially tens of millions of possible users for each 
toll transaction. However, there are nevertheless still drawbacks with such 
conventional approadies to automatic toll paying. For exanple, in the Chasek 
system the toll transaction inherendy reveals the identity of the vehicle - and 
therefore inherently reveals the identity of the vehicle owner/driver. This may 
10 provide a significant intrusion into the expeaed privacy of individuals in a 
society which is presently accustomed to anonymous highway toll payment 
transactions using untraceable cash/coins or the like. 

Furthermore, the Chasek approach requires an initial inten-ogation by a 
15 microwave transponder located at the toll plaza. This implies at least four 
phases of required bi-directional communication (e.g. the initial interrogating 
downlink communication, a first iqjlink communication of vehicle 
identification, etc., a second downlink communication of the computed toll 
'amount and a second uplink communication indicating a lack of a negative 
20 -^balance in the vehicle transponder. Not only does the described four-phase 
communication inherently require a considerable time and loss of anonymity to 
the transaction, it also fails to efiFectively provide for real-time 
cryptographically verified debit of die prepaid electronic money balance. 
Accordingly, such systems are more susceptible to erroneous and/or fraudulent 
25 transactions. 
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Although Chasek refers to security being achieved by "crypto-insertion 
codes", the only discussion of any cryptogr^hy is a brief reference to the 
determination of a hi^way entry code from a given vehicle transponder 
identification code using a "cryptographic sequence". Presumably this would 
5 provide some security against fraudulent toll minimization by use of false 
hi^way entry rjatn (for "closed" toll hi^way situations). However, it does 
not ^jpear to ofiFer any other security against possible fraudulent activity- — and 
it clearly offers no anonymity to the vehicle owners or operators traveling 
along the hi^way. 

10 

BRIEF SUMMARY OF THE INVENTION 

A presently preferred exen^lary embodiment of this invention achieves 
especially efficient bi-directional automatic toll payment communications 

15 utilizing anonymous untraceable electronic checks communicated in 

cryptogrsphically sealed envelopes with openers while utilizing, if desired, as 
few as three phases of actual data communication for each complete toll 
transaction (including a fiilly cryptographically verified debiting of smart card 
electronic money). Such eflBcient communication minimizes the time required 

20 to tx)nplete each toll transaction and thus facilitates use at hi^ vehicle speeds. 



In a non-data-communicating preliminary initialization stage, each IVU 
prepares an initial "committ" data package which already includes a portion of 
an anonymous cryptographically untraceable electronic check- Due to the very 
25 nature of the d^ta in such package, it is extremely likely to be unique insofar 
all other toll transactions are concerned. Thus it conveniently also serves as a 
transaction identity code for authenticating and linking subsequent phases of 
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the toll collection transaction. When an IVU comes within the communication 
"footprint" of an RCS (i.e., the hi^way area in which reliable communication 
with an IVU is possible, or in otherwards, the microwave communication 
zone), this pre-configured "commit" data package is immediately and 
5 repetitively transmitted in an i^link mode to the nearest RCS at a toll plaza. 
When an RCS detects successful receipt of a valid up-link "commit" data 
package, then it corrputes a retum down-link "challenge" data package 
(typically including a confuted toll amount based, at least in part, upon 
vehicle classification, highway entrance point and perh^s other data included 

10 in the first up-link data package). This second "challenge" data package also 
preferably includes a shortened encrypted version of at least some of the first 
commit dnr^ package (e.g., the transaction identity code) so as to authenticate 
the RCS (i.e. before the IVU effects a cash disbursement to the RCS). The 
"challenge" data is communicated on a down-link to the appropriate IVU. 

15 When an IVU successfully receives an authentic "challenge" data package (i.e., 
one carrying transaction identity data associated with its own earlier "commit" 
data package), then an appropriate toll amount is debited from an associated 
.smart card and suitable cong^letion of the untraceable electronic check in that 
amount (together with the cryptographic opener, linkage data and 

20 .cryptographically secured verification of a smart card debit) is collected in a 
third "p)ayment" di^t^ package that is communicated on an up-liiik from the 
rVU to the RCS, thus completing one entire toll transaction. 

Merely increasing communication bandwidth without limit to 
25 accommodate more data transmission in less time (e.g., at high vehicle speeds) 
is typically not practical due to regulatory constraints on utilized bandwidth. 



wo 95/10147 •CT/US94/ 11453 



7 



Typically only about lOMHz of bandwidth is provided by regulation for such 
applications. Thus there is further need for e£5cient data protocols. 

As already briefly mentioned, since the data representing an untraceable 
5 electronic check is extremely likely to be unique with respect to all other toll 
transactions, a portion of that data is advantageously also utilized as transaction 
identity Hata communicated in the first "commit" phase of the bi-directional 
communication process. A shortened encrypted version of this transaction 
identity data (e.g. encrypted with a secret Data Encryption Standard or "DES" 

10 key shared by the IVU and RCS) may then be returned in the "challenge" data 
so as to authenticate the RCS to the IVU before a toll debit is efifeaed In 
addition, to provide further multi-lane fijnctionality, transaction sequence 
and/or transaction lane data may be generated so as to be unique within a 
given plaza environment over a time duration longer than any expected toll 

15 transaction. This additional transaction identification data may be included in 
the "challenge" and "payment" phases of each transaction so that a given RCS 
may appropriately associate different data packets involved in a given 
transaction and thus simultaneously process of toll transactions with a plurality 
of rVLTs. A hi^er level local area network is also preferably provided 

20 between RCS*s at a multi-lane facility so that cross-lane data may be redirected 
at the hi^er LAN level to the appropriate RCS. Such cryptographically secure 
transaction linkage da t?^ (e.g., the transaction identity data, the transaaion 
sequence data and/or the transaction lane data) is also preferably utilized to 
provide undeniable proof of toll payment in case the smart card is actually 

25 debited by the toll amount but, for some reason, such debiting is not properly 
recorded by the RCS and, as a consequence, enforcement provisions are 
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subsequently taken against the vehicle in question (e.g. by triggering a 
photogr^h of the vehicle license plate). 

The preferred exenplary embodiment also utilizes a down-link timing . 
5 controller so as to coordinate downlink communication on adjacent lanes and 
avoid potential cross-lane down-link interference by preventing simultaneous 
downlink communication on adjacent lanes (and/or nearby lanes) of a multi- 
lane toll plaza. 

10 If desired, the system may be designed with an ability to handle both 

"open" and "closed" toll highway configurations. In an open toll highway, a 
fixed toll may be charged for each vehicle (or vehicle class) at each toll plaza. 
In a closed highway environment, a particular toll is typically computed as a 
function of the highway entrance point for a particular vehicle. Such entrance 

15 point identity would be communicated through the IVU by an RCS located at 
the entrance point and then stored so as to become part of the first "commit" 
phase of communication by the IVU when it next encounters an RCS at some 
toll plaza along the hi^way (e.g., possibly at an exit ramp). 

20 The exenplary embodiment of this invention is particularly designed 

primarily for use in a pre-payment environment (e.g. where there is sufficient 
pre-paid electronic money in the IVU-associated smart card to pay the 
requested toll). However, if desired, the same system may also be arranged to 
handle post-payment scenarios. For example, if a driver realizes that his or her 

25 smart card may not contain sufScient remaining electronic money to pay the 
upcoming toU, then the IVU may be conditioned (e.g. via suitable keyboard 
entry) to revert to an optional post-payment mode wherein vehicle^person 
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identity is transmitted to the RCS. This permits the RCS and associated toll 
plaza conputer to generate a post-payment bill or invoice to the appropriate 
alternate charging process (e.g. an approved credit card, post-payment billing 
system, etc.). A PIN code may be required before post-payment is pemiitted 
5 to minimize the chance of a smart card revealing the identity of its o^vner 
without the owner's consent 

In the preferred exen5)lary embodiment, all real time data processing 
and d?^ t;^ communication is done within and between the IVU and RCS. In the 

10 exemplary embodiment, an IVU begins the data dialog when it self-triggers 
itself into an up-link mode of operation as a result of detecting a predetermined 
threshold of ambient rf level from an RCS. In the preferred exenplary 
embodiment, modulated backscatter of a continuous wave (CW) microwave 
signal is used to transmit data in the up-link data direction. Accordingly, each 

15 RCS normally operates in a passive uplink mode so as to provide the requisite 
CW microwave carrier signal enabling an up-link data transmission as soon as 
an rVU comes v^thin its communication footprint. 

To better permit the requisite high speed real time data processing and 
20 commimication events required for real time automatic toll collection, the 
smart card utilized in the exemplary embodiment is preferably configured to 
process Hata and to communicate in a hidi speed mode wiien interfaced with 
an IVU. However, the same smart card may revert to standard slower speed 
processing and data communication at other times such that the electronic 
25 money contained in the smart card may be used for other purposes in addition 
to automatic toll collection. 
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A bidirectional microwave communication link enploying modulated 
backscatter for short range high speed data communications suitable for use 
with this invention is known in the prior art. For exan^le, reference is made 
to the following prior issued U.S. patents, the entire content of each of which 
5 is hereby incorporated by reference. 



Cryptographic processes for use in generating and communicating 
anonymous untraceable electronic checks communicated in cryptographically 
sealed envelopes with openers and suitable for use in the exemplary 
15 embodiment of this invention are also known in the prior art. For example, the 
reader is referred to the following related prior issued U.S. patents, the entire 
content of each of which is hereby incorporated by reference: 

U.S. Patent No. 4,759,063 - Chaum (1988) 
20 ^ U.S. Patent No. 4,926,480 - Chaum (1990) 
U.S. Patent No. 5,131,039 - Chaum (1992) 

As those in the art will recognize from the Chaum references, a blind 
signature system utilizing public key cryptography (e.g. the Rivest Shamir- 
25 Adleman or "RSA'* cryptosystem) may be used for generating 

cryptographically secured anonymous untraceable electronic checks wiiich may 
be communicated, for exanple, in a cryptographically sealed envelope with 



10 



U.S. Patent No. 4,075,632 - Baldwin et al (1978) 
U.S. Patent No. 4,739,328 - Koelle et al (1988) 
U.S. Patent No. 5,030,807 - Landt et al (1991) 
U.S. Patent No. 5, 055,659 - Hendrick et al (1991) 



wo 95/10147 




:TAJS94/11453 



11 



opener. Besides anonymity in cash transactions, the use of such public key 
ciyptogr^hic blind signanire systems also provides enhanced cryptogr^hic 
security whDe yet relaxing the requirements for tamper resistant or tanqjer 
proof enclosures for various system components. In particular, as those in the 
5 art will appreciate, in a public key cryptosystem, only one key (e.g., the private 
key) of a public key cryptosystem pair needs to be treated in tanper resistant 
or tanper proof manner. Accordingly, if one can anange to use the private 
key only at a relatively few and secure locations (e.g. at the premises of a bank 
when a smart card is being filled with electronic money), then one can 

10 ininimize the need for relatively expensive and con^jlextanper proof or 

tamper resistant facilities elsewhere in the cryptosystem A high speed version 
may use a secret key shared between a tamper-resistant IVU (SC) and a 
tanper-resistant RCS. 



15 Instead of a removable smart card, the IVU may itself pemianently 

incorporate a smart card chip (i.e., to be used in lieu of a removable smart 
card). Such an IVU could be more easily sealed for exterior mounting such 
might be required on motorcycles and the like. Such an IVU could also be 
produced at less cost and in a smaller size. All attributes regarding privacy 

20 and security would be preserved. 



However, use of such public key cryptography typically suffers the 
disadvantage of requiring more voluminous flata transfers (i.e., larger 
bandwidth) than for conventional cryptosystems (e.g. as in DES or the like 
25 where a single secret key is utilized by both the message sender and the 
message receiver and where both the message sender and receiver must 
therefore maintain such secret key and tamper proof or tamper resistant 
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facilities). Accordingly, if more sophisticated public key cryptogr^hic 
systems are to be utilized in an automatic toll payment system, then it is 
especially necessary to utilize very eflBcient data communication protocols and 
formats so as to ensure that there is arr^Dle time available for communicating 
5 all of the requisite data within a very short time window (which varies 
inversely with vehicle speed). The need for use of sophisticated data 
formatting and protocols becomes especially significant when multi-lane 
environments are envisioned and/or when multiple simultaneous IVU toll 
paying transactions are envisioned at multi-lane toll plazas and the like. To 
10 accon55lish all of these desired goals, extremely high data security and 
communication efiBciency must be simultaneously achieved. This invention 
provides a particularly secure and efiScient way to organize and operate such 
an automatic real time highway toll collection system. 

15 BRIEF DESCRIPTION OF THE DRAWINGS 

The invention will be more completely understood and appreciated by 
careful study of the following more detailed description of a presently 
preferred exen^^laiy embodiment of the invention taken in conjunction with the 
20 accompanying drawings, of which: 

FIGURE 1 is a diagrammatic perspective view of a multi-lane toll plaza 
incorporating an exemplary automatic real time highway toll collection 
system in accordance with this invention; 

25 

FIGURE 2 is a block diagram of some major toll collection system 
components in the exemplary embodiment of FIGURE 1 ; 
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FIGURES 2A, 2B and 2C depia exemplary operation of a downlink 
tuning controller so as to prevent interference between adjacent lanes in 
the multi-lane environment of FIGURE 1; 

5 FIGURE 2D is a sirq^lified block diagram of a possible violation 

enforcement subsystem for use with the embodiment of FIGURE 1; 

FIGURE 3 is a block diagram of an exemplary in-vehicle (TVU) for 
use in the embodiment of FIGURE 1; 

10 

FIGURES 3A and 3B depict an exemplary housing and a possible 
keyboard/screen user interface for the IVU of FIGURE 3; 

FIGURE 3C is a logic sequence human interface diagram showing an 
15 exen^lary human interface with the IVU of FIGURES 3, 3 A and 3B; 

FIGURE 3D is a schematic depiaion of the link ASIC (application 
specific integrated circuit) utilized in the FIGURE 3 IVU; 

20 FIGURE 4 is a block diagram of an exemplary roadside collection 

station (RCS) used in the embodiment of FIGURE 1; 

FIGURE 4 A is a logic block diagram of an exenq^lary uplink control 
process for use in the RCS of HGURE 4; 



25 
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FIGURES 5, 5A and 5B depia data package flows in the exenplary 
embodiment of FIGURE 1 for both uplink and downlink 
communication; and 

5 FIGURES 5C and 5D depict exemplary WRITE and SELECT 

command signalling sequences. 

pmn n> PESCRimqv of the d p awt ngs 

10 EXEMPLARY EMBODIMENT 

FIGURE 1 schematically depicts a typical multi-lane toll plaza 
environment having four lanes (0-3) respectively associated with roadside 

15 collection stations (RCS) 20a (not shown), 20b, 20c, 20d Each RCS 

communicates over a hi^ speed short range microwave or rf communication 
link 22 with in-vehicle units (TVU) 34 located in either a single vehicle in its 
respective lane (e.g. see lane 1 in FIGURE 1) or plural vehicles in its 
respective lane (e.g. see the pair of motorcycles in lane 2 of FIGURE 1) while 

20 the vehicle passes throu^ an RCS communication footprint 24. In this 

document the terms the microwave and/or rf are used to refer to any portion of 
the 4adio jBpequency spectrum suitable for a short-range communication 
between an FVU and RCS. As will be appreciated, the dimensions of the 
footprint are a combined function of the radiation pattern of the rf antennae 

25 associated with both the RCS and the rVU. The limited time duration over 
which a given IVU is present within the RCS communication footprint 24 
(which time duration will, of course, also be inversely related to vehicle speed) 
places a very severe limitation on the time that is available to complete a bi- 
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directional toll payment transaction. For typical speeds and antenna radiation 
patterns, it is presently anticipated that only a relatively few milliseconds may 
ultimately be available to complete such a transaction. Given the vagaries of 
microwave communication over short ranges between relatively moving 
5 antennae and the need to communicate reliably a considerable quantity of Hata 
requires hi^y eflBcient data protocols and formats. 

As will also be ^^preciated, the multi-lane toll plaza environment of 
FIGURE 1 may cause misdirected cross-lane data read-in to occur. That is, it 

10 is quite possible for an IVU in one of the lanes to successfully pass uplink data 
to an RCS other than the RCS that is nominally associated with that vehicle's 
actual highway lane. Unless constrained in some manner, it is also possible 
that a vehicle may be changing lanes during passage through the toll plaza. To 
accommodate reconciliation of cross-lane data read-in and to otherwise provide 

15 timing control over downlinks (and thus to help minimize cross-lane downlink 
interference between adjacent lanes), the RCS units 20 are interconnected with 
a plaza computer local area network (LAN) and a downlink plaza timing 
controller via cabling 26. 

20 A block diagram of the exen^^lary system is depicted in more detail at 

FIGURE 2. Here, toll plaza 1 is schematically shown to include four lanes, 
each of which is respectively associated with an RCS 20, the RCS*s 20a-20d 
being interconnected with piaza 1 con^uter 30 (e.g., a 486-based 33 MHz 8 
MByte RAM 40 MByte hard disk PC with special application software mnning 

25 under Windows V3.1) and downlink plaza 1 controller 32 via a LAN and other 
wiring within cabling 26. The hi^ speed short range bi-directional microwave 
communication links 22 are also depicted with the in-vehicle unit (IVU) 34 of 
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an associated vehicle travelling along that respective highway lane. As 
depicted, each IVU 34 is interconnected to a respectively associated removable 
smart card (SC) 36a-36d In turn, plaza 1 computer 30 is interconnected with 
other plaza con5)uters at other toll plazas and to a bank reload con^^uter 40 
5 (e.g. via a dial-t^) link, exchange of floppy disk or tapes) typically positioned 
in a secure (i.e., tanper resistant or tamper proof) bank facility 42. Reload 
..stations 44 may then be remotely connected to the bank reload computer 40 
»via another LAN (e.g. with reload stations being located at a gas station 46 or 
the like as illustrated in FIGURE 2). A smart card 36 may then be removably 
10 interconnected with a reload station 44 and reloaded with electronic money in 
a cryptographically secure way via the bank reload computer 40 (which may 
be located in a tamper resistant or tamper proof bank environment if the 
private key of a public key cryptosystem pair is required as part of the 
reloading process). 

15 

The Reload Computer may be installed with an internal Kryptor 
mounted in an ISA e^q^ansion slot. The Kryptor generates blank electronic 
checks and balance data for transmission to a remote Reload Station. The 
^ Reload Station 44 is the physical device into which the smart card is inserted 
20. Jor receiving blank checks and a balance. The Reload Station can be 

physically the same as a DigiCash Pay Station (available from DigiCash b.v., 
419 Kruislaan, 1098 VA Amsterdam, The Netherlands), but with firmware 
suitably adapted to the toll application. The Reload Station may be linked to 
the Reload Computer over a twisted-pair LAtSf operating at 38 KBaud. 

25 

The plaza area network (LAN) that links the Plaza Computer with one 
or more RCS's, Reload Computers and Reload Stations may be a multi-access, 
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twisted-pair, asynchronous network using RS485 signal levels capable of data 
rates up to 38'KBaud and distances to 1 Km. 

The general type of short range microwave communications link 
5 en^^loyed in the exemplary embodiment has already been successfully applied 
within the European rail network. For example, in a railroad environment, 
modulated backscatter has been used to provide automatic vehicle identification 
(AVI) with backscatter data modulator "tags" being located on the underside of 
rail vehicles and an active microwave CW source RCS link controller being 

10 located on the ground between the rails. The same technology has also been 
applied in reverse to automatic train control (ATC) with the CW active 
microwave interrogator located on the underside of locomotives and 
backscatter data modulator "tags" located on the ground between the rails. 
Existing interrogators and tags using such communication technology are 

15 commercially available as part of the Dynicom system fixim Amtech 
Corporation, 17301 Preston Road, Building ElOO, Dallas, Texas 75252. 

The controlling firmware and hardware in such existing commercially 
available units may be modified so as to support hi^ performance smart card- 

20 based road pricing applications in accordance with this invention. In such 
specialized road pricing applications (e.g., toll payments), uplink data received 
from the rVU must be cryptographically processed in real time (e.g. in suitable 
cryptographic da t3 processing circuits also associated with the RCS) since the 
result of such computations on uplink data is necessary to generate downlink 

25 messages back to the IVU in real time. The IVU, in turn, must perform real 
time processing of downlink messages in order to generate concluding uplink 
messages which, among other things, cryptographically verify the actual 
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conpleted debiting of electronic money from an associated smart card. Thus, 
each road pricing transaction requires a sequence of at least three (i.e., uplink, 
downlink, and i-plink) messages. For special purposes, additional data 
messages may also be necessary or desirable as will be appreciated by those in 
5 the art 

Consequendy, the demanding real time nature of road pricing 
:^3plications require optimization of: 1) reporting of uplinked data received 
from the rVU to the cryptographic data processing circuits at the RCS, 2) high 
10 speed communications between the microwave data communication circuits 
and the cryptographic data processing circuits using an efficient inter-circuit 
protocol at the RCS, and 3) eflBcient downlink data transmissions from the 
cryptographic data processing circuits to the IVU with automatic verification 
and retry capabilities. 

15 

The RCS and IVU of this invention siq^port -a bi-directional short range 
microwave communication link- The link may operate in a half duplex mode 
(i.e. where transmission occurs in only one direction at a time). In the 
• vcxen^lary embodiment, initial data communication occurs fi*om the IVU to the 

20 :RCS (wiiich is defined as the "uplink" direction of data transmission). The 
RCS may switch the direction of data communication by transmitting a special 
primitive listen command to the IVU. Once the IVU switches from a transmit 
to a listen mode, then data transmission from the RCS to the IVU may be 
initiated (and this is defined as the downlink direction of data transmission). 

25 Once the RCS completes a downlink message, it automatically reverts to the 
passive, uplink mode in anticipation of receiving uplink data packages. 
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Unfortunately, when modolaied downlink microwave transmissions are 
employed, it is easy to have cross-lane interference if two adjacent RCS*s 
simultaneously transmit downlink data. As will be ^jpreciated, there may be 
direct interference between closely spaced and/or overlapping radiation patterns 
5 of microwave signals nominally operating at a relatively closely spaced carrier 
frequency on adjacent lanes. In addition, in a real life toll plaza environment, 
such microwaves may easily be reflected from surfaces such as the sides of 
passing vehicles (e.g. large metallic tmck bodies and the like) so as to cause 
tenporary dislocation of the intended radiation pattern from one lane into an 
10 adjacent lane. 

Accordingly, in accordance with the exemplary embodiment of this 
invention, a downlink timing plaza controller 32 is en^loyed to ensure against 
simultaneous downlink communications from RCS's in adjacent lanes. One 

15 possible arrangement is depicted at FIGURE 2A wiiere downlinks are 

permitted only simultaneously in even numbered lanes for a first time period 
and then in odd numbered links for a second time period — followed by a time 
slot during which CW microwave power is provided so that uplink 
communications are permitted to occur (from all lanes simultaneously). In the 

20 embodiment of FIGURE 2A, a relatively longer time period is provided for 
uplinks where a more conplicated and secure public key cryptosystem form of 
cryptography is utilized (thus requiring the transmission of relatively greater 
amounts of data in the uplink direction while also permitting greater use of 
relatively cheaper non-tamperproof equipment disseminated througjiout the 

25 system). The embodiment of FIGURE 2B is similar to that of FIGURE 2A 
except that a relatively shorter time is provided for uplinks (as would be the 
case, for example, where less sophisticated cryptosystems are utilized with the 
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artendant need to provide more secure tamper-proof components disseminated 
at critical points throughout the system). 

While it is possible to realize the downlink plaza timing controller 32 
5 as a fixed clock granting alternate even-numbered and odd-numbered lane 
downlinks to occur between suitable iq^link time periods, it is possible to make 
rciore eflBcient use of time in lifter traflBc environments where it may be 
unnecessary to provide downlink from both even and odd lanes during a given 
time period For example, the downlink plaza controller 32 may comprise a 

10 programmed microprocessor operated in accordance with an optimizing 

programmed process similar to that depicted in block diagram form at FIGURE 
2C. Here, the downlink controller 32 would most commonly be found 
operating in a tight loop around the downlink request query 50 (e.g. testing for 
the presence of any downlink communication request from any one of the 

15 RCS's at this particular plaza). Once such a downlink request has been 

detected, then control would pass to block 52 to determine whether the request 
has emanated from an odd or even numbered lane. If an even numbered lane 
is requesting a downlink, then that request may be immediately satisfied by 
beginning the grant of an even-numbered lane request at 54 and thereafter 

20 continuing to test for more possible incoming requests at 56 (e.g. during the 
ongoing already granted downlink for even lanes). If not, then control may be 
immediately be passed to block 58 where the granted even lane downlink 
request may be extended if feasible (e.g. to more assuredly permit a successfial 
downlink communication and/or to permit possibly additional downlink 

25 communications to occur on even numbered lanes provided that there is still 
sufficient RCS communication footprint time available to complete a 
transaction). On the other hand, if additional requests are deteaed at 56, then 
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a test is made at 60 to determine whether the additional new requests cx)me 
from odd or even numbered lanes. If the new requests come from even 
numbered lanes only, then control is again passed to block 58 for processing as 
already described However, if additional requests have been detected from 
5 odd numbered lanes, then control is passed to block 62 where the added lane 
downlink request is granted (e.g. an additional two milliseconds for downlink 
communication in the odd lanes) at the expiration of the just previous granted 
downlink communication (e.g. in even numbered lanes). Thereafter, control is 
passed to block 64 where uplink communications are enabled by transmitting 
10 from the RCS's only unmodulated CVsf microwave power. When the uplink 
mode times out, control is again passed to block 50 to poll for more downlink 
requests. 

Of course, if at block 52 the first detected request had been for an odd 
15 lane, then control could have passed to block 54a and subsequent blocks 56a, 
58a, 60a and 62a which are all directly analogous to blocks 54-62 except for 
the interchange of odd and even-numbered lane associations as should now be 
apparent from FIGURE 2C. More sophisticated downlink timing control could 
provide individual grants as requested — for as long as necessary to 
20 successfully conclude the downlink phase or until a predetermined time-out — 
so long as no downlink requests are simultaneously granted for adjacent lane 
RCS's. 

As may be appreciated, as traffic density increases in the multi-lane 
25 environment, then operation of an optimization downlink control process such 
as that depicted in FIGURE 2C may ultimately tend toward fixed time 
allocations such as depicted in FIGURES 2A or 2B. It is possible, in this 
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example^ to provide three or four downlink grants during the 10 to 20 
milliseconds duration of an RCS communication footprint with an IVU — thus 
helping to ensure a successful completed toll transaction at some point 

5 Multi-lane operations may involve TVU-equipped vehicles travelling 

. freely in two or more adjacent lanes. In the multi-lane environment there may 
, be the opportunity for interference between adjacent RCSs and there may also 
_be the opportunity to confiise IVUs between closely spaced adjacent vehicles 
(e.g. motorcycles). In addition to downlink-to-downlink multi-lane 
10 interference, it is also possible to have interference between a downlink and an 
uplink in adjacent lanes. This latter problem arises when a particular RCS is 
tiying to receive an uplink message while any other RCS is transmitting a 
downlink message. Experience has shown that the transmission of a downlink 
message is likely to corri5)t \43link messages across the entire pletza. This 
15 particular problem also may be solved by ensuring that all stations restrict 
downlink message transmissions to a selected time window authorized by the 
downlink controller (i.e., downlink grant interval). Thus, no RCS will be 
required to receive vqDlink messages during an interval in which some other 
RCS is transmitting a downlink message. 

20 

As part of an enforcement system, a pjrogrammed (or hard-wired) lane 
controller 100 may be provided as shown in FIGURE 2D for each lane of 
trafBc at the toll plaza. Here, an RCS 20 provides vehicle classification 
information on line 102 (e.g. as provided by i^link data communications from 
25 the rVU involved in a current toll payment process) as well as payment status 
information (e.g. the toll amount actually paid if any, as indicated by 
cryptographically secured uplink payment verification data) on line 104. Via 
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other conventional vehicle classification deteaion systems 106, the lane 
controller also receives vehicle classification data in an independent manner for 
the same vehicle then passing through a particular lane of the toll plaza. Yet 
further, the lane controller may have conventional vehicle presence detectors 
5 108 (located before the RCS communication footprint) and 110 (located after 
the RCS communication footprint). In this manner, the lane controller 100 
may verify that vehicle classification information is correct and that 
cryptographically verified payment of the correct toll amount for that 
classification of vehicle has actually been received before presence detector 

10 110 indicates that the vehicle has passed beyond the RCS communication 

footprint. If any monitored event fails to be satisfied at that time, then the lane 
controller 100 may trigger a conventional video enforcement system 1 12 or 
otherwise call attention to the possible nonpayment of a proper toll by a 
particular vehicle (e.g. by applying some sort of detectable marker to the 

15 vehicle, by triggering an alarm, etc.). 

As explained, the smart card is debited just prior to the moment the 
rVU issues the payment message. However, in some cases, the vehicle may 
exit the microwave communication zone prior to the correct readout of all 
20 payment frames by the RCS. In this case, the smart card would have been 
correctly debited, but verification of payment would not have been received by 
the RCS. This event will trigger the enforcement system and cause a fine to 
be issued to the owner of the vehicle. 

25 In such circumstances, the system architecture is designed to allow the 

vehicle owner to prove that he made payment and, thereby, avoid the fine. In 
order to achieve this capability, the IVU maintains an 8 digit alphanumeric 
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code corresponding to each transaction con«:tly debited Once the notice of 
fine is received, the vehicle owner may send to the toll authority the code 
connesponding to the transaction in question as proof of payment In the event 
that the vehicle exits the microwave communication zone prior to the receipt of 
5 the challenge message, no payment data shall be released by the IVU and the 
smart card shall not be debited In this instance, the vehicle owner shall be 
required to remit the toll and any associated fines. 

The above-referenced cryptographically secured electronic money 

10 provides a smart card-based toll payment system that is advantageous in at 
least two ways. 1) it provides off-line pre-payments with multi-party security 
using a sophisticated public key cryptosystem and 2) it provides a hidily 
eflBcient cryptographically secure payment system. It is believed feasible to 
si^port smart card-based road-pricing toll payment systems with transactions 

15 times of less than a few (e.g., 17) milliseconds. The exemplary cryptosystem 
secured electronic money in smart cards is currently available from DigiCash 
b.v., 419 Kruislaan, 1098 VA Amsterdam, The Netherlands, and is currently in 
use for payments within ofiBce buildings where the smart card can be used for 
purchasing cofifee, f>aying for food, making photocopies or sending facsimiles. 

20 Even thouda an extremely sophisticated cryptogr^hically secured electronic 
money system is involved, it nevertheless can be used even for such low value 
payments because of its very low transaction costs (e.g. due to the possible ofiF- 
line verification of anonymous electronic checks and a cryptogr^hically 
sophisticated public key cryptosystem which eliminates the need for tamper- 

25 proof payment terminals). 
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The present invention, in effect, integrates, adapts and improves the 
prior Amtech and DigiCash technologies so as to achieve a smart card-based 
road pricing system complete with bi-directional microwave communication 
link. 

5 

A block diagram of an exercplary IVU 34 is depicted at FIGURE 3. 
The microwave antenna 300 provides a rf transducer for both downlink and 
uplink communications with an RCS. Current microwave frequency 
allocations for applications such as here involved may typically occur within 

10 bands located at ^jproximately 915 MHz, 2.5GH2 and 5.8 GHz. The antenna 
may be of any acceptable conventional design providing appropriate gain (e.g., 
perhaps lOdB) and directivity (not so inportant for the TVU). A relatively 
small multi-element microstrip patch antenna array is probably best suited to 
the relatively high frequency microwave environment and relatively small 

15 acceptable size limits for the IVU. Typically, the IVU may be only sli^tly 
larger than the usual credit card or smart card and may be affixed in any 
convenient way (e.g. with Velcro® fasteners in the windshield area of the 
vehicle) so as to provide unimpeded microwave communication with an 
overhead RCS. If the RCS is mounted on an overhead gantry then the top 

20 center portion of the windshield above the rear view mirror may be preferred 
If a roadside RCS mounting portion is used, then a lower left hand (driver) 
side windshield position may be pjreferred. 

The analog rf circuits 302 include a conventional downlink microwave 
25 dR t?^ demodulator 304 and a conventional uplink microwave data modulator 
306 so as to provide uplink/downlink logic/rf data links to/from the IVU link 
ASIC 308. As will be explained in more detail in connection with Figure 3D, 
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the link ASIC 308 may be any suitable custom ASIC (e.g., an existing ASIC 
available from amtech designed specifically for bidirectional communications 
across a microwave link) which provides a communication interface and buffer 
in both the downlink and uplink directions. It is interfaced with the IVU link 
5 controller (e.g. any suitable microconputer, e.g., a Motorola® 68 HC 705) that 
^interfaces, in tum, with a smart card controller 312 (another suitable 
microcon^juter, e.g., a Motorola 68HC11). The smart card controller 312 is 
-connected to smart card 36 (e.g., a Motorola 68 HC055C21) at a conventional 
removable electrical contact smart card connector interface 314. Human 

10 interface is provided via keypad 316 and LCD display 318, LCD's 320 and 322 
(or a suitable single multi-color LED to provide, e.g., green and red signals 
representing acceptance or non-acceptance of payment, or similar types of 
yes/no go/stop status indications) and an audible output buzzer 324 (e.g., to 
audibly intem^Dt the user's attention when urgent user control is needed or to 

15 audibly indicate success, failure or key click sounds). The primary function of 
the buzzer is to provide audio feedback without the necessity of reading the 
LCD display and/or LEDs. 

The IVU 34 is pictorially represented at FIGURE 3 A with smart card 
20 36 inserted thercwithin. The keyboard is self-evident as is a multi-color LED 
320/322. The LCD display 318 is depicted in more detail at FIGURE 3B. 
The LCD display 318 may include, for example, a display of the current smart 
card balance, the current smart card status, the time of the last transaction, the 
amount of the last transaction and the status of the last transaction (the two 
25 status fields providing human interface for evoking keyboard responses from a 
human operator so as to cause the smart card controller to index throudi 
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human interface conputer program (firmware) modules such as depicted in 
HGURE 3C). 

For example, as depicted at FIGURE 3C, the nominal quiescent state of 
5 smart card and smart card controller 312 may be as shown in block 400 where 
the pressing of any key causes one to transfer to block 402. There a status 
indication in the display asks an operator whether set vp of the FVU is 
requested If the answer is "yes", (e.g. as may be signalled via a 
predetermined one of the keys on the keyboard 316), then control is transferred 

10 to block 404 v^ere the operator is requested to detemiine whether a change is 
required in the payment method. If so, then selection between post-payment 
and pre-payment techniques is selected at blocks 404a and 404b respectively 
before control is passed back to block 406 (to ^\ilich control is also passed if 
the operator indicates that no change in payment method is requested). As 

15 should now be self evident from FIGURE 3C, similar operator interface 
changes may be eflfected at blocks 406, 408 and 410 (in association with the 
respectively associated sub-decision blocks similarly numbered but with 
suflBxes a and b). At block 412, the operator may enter a sequence of 
operations 412a throu^ 412f for changing his or her p)ersonal identification 

20 number (PIN). Card status may be checked at block 414 (and 414a) while the 
prior transaction d ata (if any) may be checked by the operator at interface 416 
(and related blocks 416a-416c) before control is returned back to the nominal 
quiescent state 400. As will be recognized, many different human interfaces of 
this type may be devised and used with the IVU 34. 

25 

The link ASIC depicted in more detail at FIGURE 3D is similar to that 
used in the prior Dynicom system. A frame RAM 500 is organized into two 
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pages 0 and 1, each containing 32 frames of data, each frame containing 128 
bits. In the exemplary system, the smallest data package for transmission in 
the uplink and downlink directions is a single fi-ame of 128 bits. A scroll 
RAM 502 of 5 bit frame and 1 bit page RAM addresses is provided These 
5 addresses point to particular frames and page of RAM 500 which can 

thereafter be repetitively and sequentially addressed and output to the uplink 
' modulator 306 (via suitable logic circuits 504 e.g. to suitably format and time 
" ir^uts to the uplink modulator 306). In the exenplary embodiment, the first 
pointer in the scroll RAM 502 actually defines the number of subsequent 

10 active address pointers in the scroll RAM list 502 for scrolling at any 

particular time. The number of immediately subsequent entries in the scroll 
RAM 502 then point to successive frames of the RAM 500 that are to be 
sequentially transmitted upon command from the link controller microprocessor 
310. As will be ^^preciated, the link controller microprocessor 310 also 

15 controls the content of the scroll RAM 502. In addition, data from the 

downlink demodulator 304 may be selectively written into suitably addressed 
fimnes of RAM 500 via suitable processing logic 506. 

:r As depicted in FIGURE 3D, the link ASIC 308 conveniently may also 

20 be utilized to control rf detector tum-on ftmctions. In a normal quiescent 
mode, most of the IVU circuits will be turned "off*' so as to consen/e battery 
power. However, when ambient rf energy at the proper frequency and above a 
predetermined threshold level is detected, it is assumed that the IVU is 
appjroaching or within the communication footprint of an RCS. In response to 
25 such detection of a predetermined level of rf carrier, the TVU circuits 
automatically are fiilly turned "on" and the IVU immediately assumes the 
"commit" mode of vq^link data communication so as to repetitively scroll and 
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send to the nearby RCS one or more predetermined and preformatted firames of 
data fem RAM 500. 

The rf carrier detection may be effected by a suitable co i i ipai ator 508 
5 comparing a predetermined toll plaza rf detector reference level to any detected 
ambient rf carrier and thus turn "on" the remainder of IVU 34. As should now 
be appreciated, the link controller 310 is suitably programmed in the 
exemplary embodiment so as to begin its operation in the "commit" phase by 
repetitively transmitting a first data package on the uplink to the presumed 
10 nearby RCS. Such operation continues until either a time-out expires 

following the loss of microwave signal or until the presumed nearby RCS has 
successfiilly received the first data package and, in response, has acknowledged 
such receipt by commanding the IVU to revert to a downlink mode of 
operation. 

15 

It should be remembered that the exemplary subdivisions of link ASIC, 
link controller, and SC controller do not imply a particular inplementation 
level of integratioa The separations are instead rather arbitrary and based 
mostly upon convenience in creatomg a demonstration embodiment using 
20 preexisting technology of Amtech and DigiCash to the extent possible. 

During the downlink mode, a second data package is received from the 
RCS and stored at suitably addressed frames of RAM 500 from which the 
downlink Ham may be passed on to the smart card controller 312 and/or smart 
25 card 36 via die IVU liiik controller 310 for real time processing. The smart 
card 36 and/or smart card controller 312 then generates appropriate return data 
packages that are appropriately formatted in frame RAM 500 via link 
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controller 310 for subsequent transmission back to the RCS in an i^link mode 
of operation, 

A block diagram of the RCS 20 is depicted at FIGURE 4. As with the 
5 TVU, antenna 600 may be of any suitable conventional design for a short range 
microwave communication link. Although more space may be available at the 
RCS to accommodate bulkier antenna designs (e.g., a Yagi antenna), in the 
^'Tpr gently preferred exen5)iary embodiment, antenna 600 is a multi-patch 
microstrip antenna array having a beam radiation pattern gain of about 10 dB 

10 aimed downwardly and into the e^q^ected oncoming vehicular traflBc, The RCS 
communication footprint may typically encompass only a few meters of vehicle 
travel (e.g. ypically 2 or 3 meters, perh^s 4 or 6 meters) along a given 
hi^way lane — thus providing only a few milliseconds for a completed toll 
transaction at hi^er e:q5ected highway speeds (e.g., 300 Km/hr on German 

15 autobahns). The rf module 602 may be of conventional design and in 
accordance with the above-cited prior issued patents for this type of short 
range microwave bi-directional communication link. For example, it will 
include an rf oscillator 604 for generating the necessary CW microwave power 
.:that must be provided via antenna 600 to enable modulated backscatter iq^link 

20 ::data transmission fix)m the IVU. Such backscatter is conventionally monitored 
'and demodulated at 606 so as to provide uplink data to the RCS link controller 
microprocessor 608 (e.g., a Motorola® 68302). Similarly, a suitable rf 
modular 610 is included in the rf module 602 to accept downlink data from the 
RCS link controller 608 and to suitably modulate the output of oscillator 604 

25 so as to efifect downlink data communications. As will also be appreciated, the 
RCS link controller 608 will control the rf module 602 so as to generate the 
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requisite unique (i.e., "primitive") rf on-off signalling patterns as might be 
required to switch the IVU between uplink and downlink modes of operation. 

The RCS link controller 608 may be a suitable microconputer (e.g., the 
5 Motorola® 68302) equable of high speed serial data communication with 
conventional cryptographic data processing circuits 612. The Kryptor may 
typically include a suitable digital signal processor (DSP), UART and DES 
chip. For exan?;ie, the data processing circuits 612 may comprise hi^ speed 
(e.g., 1536 Kbaud) data processing circuits capable of perfomiing the requisite 

10 public key cryptosystem fimctions such as are available as a "Kryptor: i-1200 
(MPR-6000)" from Crypto AG in Zug, Switzerland As indicated, the Kryptor 
612 is also connected as a node on the plaza computer LAN so that cross-lane 
read-in data not recognized by a particular RCS 20 may be passed to the 
higher level LAN where it may be verified ofQine, after receiving all necessary 

15 frames. Furthermore, the downlink timing controller input is connected to the 
RCS link controller 608 as depicted in FIGURE 4. Accordingly, whenever the 
RCS link controller 608 wishes to transmit downlink data, unless there is 
already present a downlink grant on line 614, a downlink request must be 
generated on line 616 to the downlink controller 32. Only when a downlink 

20 grant is thereafter provided by the downlink controller on line 614 may the 
RCS link controller 608 actually effectuate a downlink data communication 
session. 

An exemplary uplink control process (e.g., to be in^lemented via 
25 firmware or software control of the RCS link controller 608) is depicted in the 
block diagram of FIGURE 4A- In the exemplary embodiment, uplink control 
is achieved on an intemq)t basis. Accordingly, it starts when an interrupt is 
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detected at blcxrk 700. Upon such interrupt, the incoming uplink frame is read 
and processed at 702. A pre-defined check sum is tested at 704 to ensure that 
the received check sum agrees with the locally calculated check sunx If not, 
then control is passed back to wait for yet another interrupt at 700 when yet a 
5 subsequent uplink Hara frame has been received. If the check sums do agree, 
then control is passed to block 706 where a check is made on the transaction 
^ndentification included within the incoming uplink frame of data. For example, 
^a plurality (e.g. 8) of the most recent incoming transaction identification data 
may be maintained in a rotating buffer for conparison against incoming 

10 transaction identification data. If the deteaed transaction identification is 
detected as being unique at 706, then it is entered into the buffers (which are 
suitably rotated so as simultaneously to drop off the oldest prior detected 
transaction ID and accept this new transaction ID at block 708 and 710). If 
the transaction ED of the incoming uplink fi:ame of data is not unique, then the 

15 fi^e data is firther tested at block 712 to see if the incoming uplink frame is 
a new firame of received data If not, then the status (e.g., Ack or Nack) of the 
incoming firame is checked at 714 (e.g. again against a suitable rotating buffer) 
if not, then the handshake counter is incremented at 716 and control is returned 
.,to the wait for intem^t at 700. Otherwise, the new status of the incoming 

20 ..fi^e is stored at 718, the handshake counter is set back to a beginning 

content of one at 720 and the incoming frame of new data is then reported to 
the kiyptor circuits for fijrther processing at 722. If the fiame is a negative 
acknowledgment (i.e. a ''Nack") to a pending downlink request, then a 
downlink message for another retry may be suitably generated and sent at 724 

25 before control is passed back to wait for another interrupt at 700. As may be 
appreciated, the real time processing at blocks 700 and 702 may be most 
conveniently carried out in "hardware" implementation while the remaining 
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blocks in FIGURE 4A may typically be carried out in firmware/software by a 
suitable microcomputer. 

The general flows of data during the preparatory "precommit" phase 
5 and three actual communication phases involved in a complete toll transaction 
for the exen^Dlary embodiment are gr^hically depicted at FIGURE 5. For 
example, d fl t? ^ representing the version of a suitable cryptographic key, the type 
of smart card, the vehicle classification, index for a cryptographically secured 
electronic money check and the electronic money check dc defining the 

10 anonymous untraceable electronic money check are all preloaded into 

s^jpropriate firames of the link ASIC RAM 500 within the IVU prior to any 
actual Hat?^ communication with an RCS. Such data is generated either from 
the smart card or smart card controller and, as indicated by arrow 800 is 
passed onwards to the link ASIC where it is stored in readiness for the next 

15 toll transaction. 

Whenever the presence of the requisite CW microwave field of an RCS 
is detected, then the IVU is fiilly turned "on" and enters the first or "commit" 
phase of uplink communication to the RCS. Prior to this time, the link 

20 controller 310 configures the link ASIC 308 to repetitively scroll and transmit 
in the i5)link direction a portion of the electronic check data dc (together with 
the other previously accumulated data already residing at the link ASIC due to 
the precommit phase of operation at some prior time). As indicated by further 
small ijplink-directed arrows in FIGURE 5, this repetitively transmined uplink 

25 data is directly passed within the RCS to the kryptor circuits via the RCS link 
controller. In turn, as soon as this data is successfiilly passed to the kryptor, 
the kryptor confutes return data and passes it back in the downlink direction 
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during a subsequent "challenge" phase of data communication as depicted by 
small downlink-directed arrows in FIGURE 5. 

A so-called "spoof-proof data may be generated as a shortened 
5 encrypted version of some or all of the commit data so as to permit the IVU to 
authenticate the RCS before any actual toll charges are debited fix)m the smart 
card. For exan^Ie, since the spoof-proof data is generated based upon uplink 
"commit" data, and since both the smart card inserted into the FVU and the 
RCS may share a traditional secret key for this purpose (e.g. in addition to 

10 cryptosystem conponents that may be utilized for the electronic money transfer 
itself), a similar shortened encryption may already have been computed during 
the precommit phase and stored at the link controller. There it is ready for 
immediate comparison with the downlink spoof-proof data generated by the 
RCS kryptor circuits and transmitted during the "challenge" phase. As 

15 depicted the "challenge" downlink data would also include digits OQ 

representing,, among other things, the amount of the confuted toll charges, the 
charge station identity, the time of the transaction, etc. As indicated by further 
little downlink-directed arrows, this "challenge" data is passed to the smart 
card via the smart card controller and link ASIC in the IVU. 

20 ^- 

Following authentication of the RCS by processing of the downlink 
"challenge" data, the IVU then generates the remainder of the transaction data 
via the smart card (e.g. the necessary columns of wrapped data W and a 
suitable cryptogr^hic opener R) which is transmitted together with the rest of 
25 the electronic check data dc to the RCS kryptor where the transaction is 

completed As will be appreciated, the data generated by the smart card at this 
time includes cryptographically secured verification data confirming that an 
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actual successfully completed debit to a valid smart card has already occurred 
such that the RCS Kryptor may with confidence know that the requisite toll 
has been fiilly paid 

5 FIGURE 5A is similar to FIGURE 5, but includes reference to specific 

frame numbers of the frame RAM 500 that mi^t be used for a relatively 
sin^jle frame protocol (e.g. such as mi^t be p)ossible with an open toll road 
system where it is not necessary to transmit highway entry point data to the 
RCS). Here, for example, fi-ames 1 and 4-7 are preformatted and stored in 

10 RAM 500 during the fjrecommit phase. Only frame 1 is actually transmitted 
during the commit phase in the uplink directioiL The contents of the command 
frame and frame 0 are then returned during the "challenge" phase in the 
downlink direction while the contents of frames 8-14 are passed in the uplink 
direction during the payment/opener phase of communication. By contrast, in 

15 the more conplex frame protocol of FIGURE 5B, the commit phase and other 
phases involve the transmission of larger numbers of data frames (e.g. so as to 
identify the highway entry point for toll calculation). 

Both described frame usages are when using a 512-bit RSA 
20 cryptosystem. This can be extended up to 768 bits for higher security. Also, 
the number of challenge digits can be increased, from 10 x 4 bits to 16 x 4 
bits. This will cause longer payment data W. If both extensions are done, 
frames 15-22 would also be used 

25 As mentioned, uplink transmission from an IVU to an RCS occurs by a 

process called backscatter modulation. The RCS transmits a continuous wave 
(CW) microwave carrier output via its anteruia. The IVU antenna reflects a 
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small portion of this energy, some of which is received by the RCS antenna. 
Additionally, the FVU is capable of switching its antenna so that it may 
alternatively reflect the incident microwave energy with hi^ efficiency or with 
low efficiency. The RCS receiver is capable of detecting the different reflected 

5 signal levels from an TVU within its read range. An FVU is designed to 
modulate the antenna with a data pattern which can be sensed and decoded by 
the RCS. The exerr^jlary protocol has been defined such that all uplink data is 
grouped into distinct frames of 128-bits each. The IVU link ASIC memory is 
partitioned into 32 frames of 128-bits each for a total of 4096-bits. Each 

10 i^jlink frame of data read from the TVU in an exemplary embodiment may 
consist of the following fields: 
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TABLE 1 



Uplink 


Frame 1 


Frame 0 


Frame N 


Init 


Nack 


Data 


Name 


Bits 


Name 


Bits 


Name 


Bits 


Txid 


64 


Pack 


32 


Udata 


104 


Udata 


48 


FeiT 


32 










Uciata 


40 










Lane 


4 


Lane 


4 






Seq 


4 


Seq 


4 


Cksl 


1 


Cksl 


1 


Cksl 


1 


FraiO 


1 


FnnO 


1 


¥wnD 


1 


ValO 


1 


ValO 


1 


Vail 


1 


FrNo 


5 


FrNo 


5 


FrNo 


5 


Cksh 


3 


Cksh 


3 


Cksh 


3 


Lobat 


1 


Lobat 


1 


Val 


1 


Sens 


1 


Sens 


1 


Sens 


1 


Fm 


3 


Fm 


3 


Fm 


3 


Total 


128 


Total 


128 


Total 


128 



Where Txid = Transaction identification (actually block 0 of the electronic 
check dc) 

25 Udata = User data 

Cksl = Check sum low 

FrmO = Frame 0 indicator 
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ValO = Validity status (e.g., Ack or Nack) 

FrNo = Frame number (0-31) 

Cksh = Check sum h 

Lobat = Low battery alami 

5 Sens = Sensitivity (Received RF level) 

Fm = Frame marker 

Fack == Frame acknowledgement bit mask 

Ferr = Frame error bit mask 

Lane = Hi^way lane number (provided by RCS) 

10 Seq = Rotating transaction sequence number (provided by RCS) 



Uplink frame numbers may be utilized and assigned as shown below: 

TABLE 2 



Frame 


0 


1 


2 


3 


0 


Nack 


Commit 


Commit 
(reserved) 


Commit 
(reserved) 


4 


Payment 
(sig) 


Payment 
(sig) 


Payment 
(sig) 


Payment 
(sig) 


8 


Payment 
(sig/chk) 


Payment 
(chk) 


Pavment 
(chk) 


Payment 
(chk) 


12 


Payment 
(chk) 


Payment 
(chk) 


Payment 
(chk/opener) 


Payment 
(reserved) 


16 


Payment 
(reserved) 


Payment 
(reserved) 


Payment 
(reserved) 


Payment 
(reserved) 


20 


Payment 
(reservedO 


Payment 
(resented) 






24 










28 
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The 5-bit FrNo field identifies the frame and provides for the selection 
of 32 unique fi-ames which provides an i^jper IVU link ASIC memory limit of 
4096-bits. 

5 The 1-bit Dack field indicates whether the frame is an acknowledgment 

of a previously received downlink message. 

The Udata fields are generally available for unrestricted use by the 
application. 

10 

The 64-bit Txid field is part of hte unique electronic check data created 
by the IVU prior to each transaction. 

The cks fields permit the RCS to reject any received frame which does 
15 not contain a valid checksum. It is the responsibility of the IVU to calculate 
and encode the checksum into each uplink data fi^me transmitted to the RCS, 
The cks field is confuted on a predetermined set of bits in every uplink frame 
read by the RCS. Frames received by the RCS without the con^ checksums 
are ignored (i.e., rejected). 

20 

The 1-bit val/lobat field is val in frames 1 throu^ 31 and lobat in 
frame 0. Val may be efficiently set or cleared by the IVU. This feature may 
be used to efficiently validate or invalidate selected regions of IVU lirik ASIC 
memory without having to rewrite all of the data. The Lobat field is available 
25 in frame 0 only and indicates the status of the IVU link ASIC battery (i.e., 
supply voltage). A Lobat equal to zero indicates that the IVU link ASIC is 
powered by the primary battery and all ftmctions are active whereas a Lobat 
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equal to one indicates that the backig? battery is active and the IVU link ASIC 
is operating with reduced functionality. 

The 1-bit sense field is reserved The IVU link ASIC sets the 
5 sensitivity bit TRUE whenever the detected microwave level exceeds a preset 
threshold. Hiis feature can optionally be used by the RCS to determine when 
a downlink transaction may be reliably initiated. 

Pack is for indicating correctly received frames, and is coded the same 

10 way. 

The 3"bit fin field is also reserved These bits are encoded into each 
fi:ame by the IVU link ASIC and used by the RCS hardware to determine 
where on fi-ame ends and the next fi^ame begins. As previously indicated all 
15 d^t^ is transferred in integral multiples of fi-ames. 



The 32-bit Ferr field is used by the IVU, as part of a negative 
acknowledgment (Nack) message, to inform the RCS which fi:ames were 
received in error. Each bit which is set to a one within Ferr indicates the 
20 firame number of a fi:ame received in error. For example, a value of 80000002 
would indicate that frames 1 and 31 were received in error. 

The 4-bit Seq is assigned by the Kryptor as a transaction sequence 
number and is incremented by one for each new Seq. The assigned Txseq is 
25 transmitted to the IVU as part of the downlink message. Once the IVU 
receives the downlink message correctly, the Seq Value is encoded into all 
subsequent uplink frames i.e., Ack and Data) in order to conserve Udata bits. 



wo 95/10147 ia^T/US94/I1453 



41 



The 4-bit Lane number is assigned by the Kryptor according to its 
assigned 5 lane number is transmitted to the IVU as part of the downlink 
message. Once the IVU receives the downlink message con^ly, the Lane 
5 value is encoded into all subsequent uplink data ftames in order to resolve 
cross lane readings. This is especially important when one considers that the 
Seq is only 4-bits long and, therefore, uniqueness would not, necessarily, be 
maintained across lanes. Of course the number of bits used by the Txseq and 
lane number does not need to be 4. This is simply a convenient and 
10 reasonable choice. 

The RCS transmits downlink data to the IVU by a process called onnDfif 
key. The continuous wave microwave output of the RCS is switched on and 
off according to the data to be transmitted to the IVU, The IVU is able to 

15 detect and decode these transitions in received microwave energy at its 

antenna- Data sent in the direction of RCS to IVU is defined as the downlink 
direction. The data rate for sending a continuous sequence of one-bits is 384 
KBaud while the data rate for sending a continuous sequence of zero-bits is 
192 KBaud. Thus, the worst case data rate for downlink data transfer is 192 

20 KBaud 

In order to initiate a downlink transaction, the RCS sends a listen 
command primitive to the IVU. The listen command primitive is special, 
insofar as the IVU is able to detect this command even while simultaneously 
25 transmitting dat^ to the RCS. Once the listen command primitive has been 
properly received, the IVU stops transmitting in anticipation of receiving data 
The RCS may then conplete the downlink transaction. 
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A downlink transaction thus consists of a command primitive optionally 
followed by a command message. A command message consists of a 
command frame optionally followed by one more data frames. The IVU 
automatically switches into transmit mode following the receipt of a valid 
5 command message over the microwave link. This feature is important since an 
rVU which remains in the listen mode cannot be detected by the RCS. A 
downlink transaction can be performed at several levels as shown below: 

a <CmdPrimxdlyxCmdFrame> 
10 b. <CmdPrim><dly><CmdFrame><E)ataFrl...DataFrN> 

where, 

<CmdPrini> = Command primitive 
<dly> = Delay 

<CmdFrame> = Command frame 
15 <DataFrN> = Data frame number N 

The type a) message can perform more complex operations such as the 
^ invalidation of selected frames. The type b) message is required to write 
actual data into the IVU link ASIC memory, 
20 - 

Command primitives, command frames, and data frames are described 
below. A command primitive is a special command used to alter the IVU 
operating mode or prepare the IVU to receive a subsequent command message. 
All command primitives consist of a command signal followed by a sequence 
25 of 16 <i a r?^ bits followed by a frame marker. The command signal and frame 
marker do not conform to the format defined by binary data The command 
signal temporarily forces the IVU into the listen mode in anticipation of 
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receiving the binaiy data which follows shortly thereafter. It is necessary for 
the rVU to enter the listen mode in order to ensure the reliable transmission of 
binary data to the IVU. 

5 During the 3 phase transaction, 2 commands may be sent by the RCS 

link controller to the IVU. After successfiil reception of the commit, the RCS 
will issue the WRITE command to write the challenge. After receiving some 
of the payment data, the RCS may issue a SELECT command to select a 
different scroll range. It may also tell the IVU to be silent after a successfiil 
10 transaction by issuing a SELECT command with the <feel> field set to 

00000000. The IVU will not "wake up'' until it has left the microwave field 
and entered a new microwave field 

After sending a command signal, there may be a short command 
15 primitive, and then a command fi:ame and data fi:ames. The command 

primitives are chosen in such a way that IVUs receiving a command primitive 
not meant for them can go back to scrolling without waiting for the command 
frame. This results in the following downlink scenario for a write command: 



Field 


Size 


Description 


Command Primitive 


Spoof 1 


8 bits 


First byte of spoof \ 


Magic 


8 bits 


First byte of spoof 1 
xorred 0x55 j 



25 

Command Frame 
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Spoof 2 


8 bits 


Second byte of spoof 


lane/seq 


8 bits 


Lane/sequence number 


res 


3 bits 


reserved 


fcnt 


5 bits 


Frame count of frames 
to come 


omd 


8 bits 


Command code 


crc 


32 bits 


32 bit crc (including 
64 bits spoolf .not sent) 


This also results in the following for a select command. 


1 Field 


Size 


Description | 


Command Primitive 


lane/seq 


8 bits 


Lane/sequence number | 


magic 


8 bits 


Lane/sequence number | 
xorred OxAA 1 


Command Frame 


feel 


32 bits 


feel 


crc 


32 bits 


32 bit crc (including 
64 bits spoof not sent) 



20 

Since selection of fi^me 0 makes no sense (it is a Nack frame), the last 
bit of the feel field actually helps distinguish between SELECT and WRITE 
commands. Therefore, only odd command codes will be allowed. 
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As stated previously, a command message always begins with a 
command ftame. A command frame may be divided into the following fields: 



TAJgLE3 



20 



Downlink 


Primitive/Command 


Data 


Downlink 

Efeelect 

Command 


Bits 


X T_ 

Name 


Bits 


Name 


bits 


Lane seq 


8 


Spoofl 


8 


Udata 


88 


Magic 


8 


Magic 


8 






feel 


32 


SpooG 


8 






Crc 


32 


Lane 


4 










Seq 


4 










ClrFack 


1 










Res 


2 










Fcnt 


5 


Res 


3 






Cmd 


8 


FrNo 


5 






Crc 


32 


Crc 


32 


















Fm 


NA 


Fm 


NA 


Total 


16/64 


Total 


16/64 


Total 


128 



25 ClrFack = 1 means clear Pack bit mask after every downlink 

command 

The command code, <Cmd> provides the mechanism to command the 
rVU as required. Initially, a single command code shall be required which will 
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cause d?r^ to be written into the selected IVU link ASIC memory. Other 
command codes shall be reserved for future unspecified functions. 

5 The <magio field is the exclusive orred value of the first byte of the 

command primitive with a constant. If the constnt is 55 (hexadecimal), it 
indicates the first byte should be interpreted as lane^sequence. If the constant 
is> AA (hexadecimal), the first byte should be integrated as the first byte of the 
spoof 

10 

The 32-bit crc is used by the IVU to verify the validity of all fi-ames 
including the command fiame. Command frames having an incorrect crc are 
ignored The fin field is used by the IVU to identify the end of command and 
Hg^ta frames. Both the spoof fields Spoof 1 and SpxxDf 2 and crc are used to 
15 ensure that a downlink message is accepted by the single IVU for which it is 
intended 

As previously stated, command messages may optionally include one or 
more downlink ^^^^ fi-ames. Downlink data firames include data to be written 
20 to TVU link ASIC memory. Each downlink data frame is divided into the 
fields as shown above. 

The FrNo field is identical to the corresponding field within uplink 
fi^mes. The IVU uses the crc to verify each frame received This technique 
25 enables the IVU to detect errors and inform the interrogator with the Nack 
fi^ime which fi^mes were received in error. The fin field is appended to the 
end of each frame, but is exclusive of the 128-bit listed 
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FraxneN = Frame other than Same 0 

Etxid = A 16-bit encrypted portion of Txid 

Frame 0 always used as a negative acknowledgement. 

5 

The rVTJ link ASIC has a memory edacity of 4096-bits and is capable 
of bi-directional communications via an microwave link- The wire link feature 
is not implemented in firaiware since it is not required for road pricing 
applications. The microwave link operates at a worst case d^tf^ rate of 192 

10 KBaud. The IVU transmits uplink messages to the RCS by scrolling throu^ 
selected fiames of data fix>m IVU link ASIC memory. In order to satisfy 
applications having different levels of performance and Hat?^ the number of 
fiames to be scrolled fi*om IVU link ASIC memory can be varied Frames are 
continuously scrolled in the sense that the selected fiames scroll repetitively. 

15 This technique allows for reliable uplink data transmissions under marginal 
microwave link conditions. When the IVU leaves a microwave field for a 
preset time interval, it automatically reverts to the commit d?^ta message. 
Thus, an RCS is able to eflficiently read out the commit data messages when an 
rVU first enters the read range. The commit data messages are automatically 

20 reloaded into the IVU ASIC link memory following each transaction over the 
microwave link- The RCS may command the IVU to scroll throu^ selected 
fiames of IVU link ASIC memory. The IVU will continue to scroll the 
selected fiames until it leaves the microwave field or receives another 
command. 

25 

The RCS is capable of bi-directional communications with the IVU at a 
worst case data rate of 192 KBaud The RCS link controller supports a serial 
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port ^?vhich allows received uplink IVU data to be transmitted to the Kryptor. 
Likewise, a Kryptor may request the RCS to transmit data downlink to the 
rVU. The RCS is designed to read uplink data in distinct frames from the 
rVU. It is possible that individual frames from the same IVU may be read in 

5 either a continuous or discontinuous fashion depending iqx^n the quality of the 
microwave link. The RCS is designed in such a way that it will receive data 
from the rVU ofiFering the strongest signal and reject data from IVUs offering 
weaker signals. In the event that two or more IVUs offer the same signal, 
neither IVU will be read It is assumed that the antenna communication zone 

10 will generally be small conq^ared to the typical IVU-t(vIVU spacing. This 
situation will minimize the probability of two or more IVUs offering the same 
signal to the RCS. In order to allow frames to be reassembled according tot he 
rVU frx5m which they originate, a 64-bit Txid is encoded into each uplink Init 
and Nack frame. This feature is important since multiple IVUs may 

15 simultaneously be located within the read range of a given RCS. The Txid is 
created by the ICU for each new transaction. Once a new Txid is received by 
the Kryptor, a 4-bit Lane number (Lane) and 4-bit transaction sequence 
(Txseq) number is assigned to that transaction- The Lane number corresponds 
/to the value given to each Kryptor by the plaza conqDuter. The Txseq is a 4- 

20 bit number which is sequentially assigned by the Kryptor for each new 

transactioiL These values are encoded into the downlink message sent to the 
ICU as part of the challenge message. Once the downlink message is correctly 
received by the IVU, the Lane and Txseq values shall be encoded into each 
Ack and Data frame. These values serve the same purpose as the Txid, but 

25 with far fewer bits (i.e., 8 vs 64-bits). Also, uplink frames may be read by 
more than one RCS, in which case the lane number may be used by the plaza 
computer to resolve conflicts (e.g., cross lane readings). 
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The RCS is C2pable of transmitting data downlink to the IVU. The 
command message includes a 16-bit encrypted version of Txid (Etxid) in order 
to ensure that only the FVU for which the message is received, accepts the 
Hata Additionally, the crc encoded into the command message is con5)uted 
5 over the full 64-bit Txid in addition to the command frame itself to further 
ensure that only the correct IVU accepts the message. Whenever an RCS 
wishes to transmit a downlink message, it asserts a downlink request signal and 
waits for a proper downlink grant signal to be asserted 

10 The RCS program code is preferably implemented in both read only 

memory (ROM) and electrically erasable read only memory (EEPROM). The 
EEPROM memory provides for convenient iqDgrades in the field over the serial 
communication port. The RCS stores all configuration parameters in both 
volatile and non-volatile memory. The storage in volatile memory provides for 

15 fast access during real time operation of the RCS. The storage in non-volatile 
memory provides for the long term reliability and security of the RCS 
configuration. The configuration EEPROM is rated for 100,000 write cycles. 
The RCS periodically restores the EEPROM configuration parameters to 
volatile memory in order to guard against the possibility of electrical noise or 

20 other interference conrq^ting the less secure volatile memory. 

In order to ensure that uplink frames of data received by the RCS can 
be correctly associated with the correct IVU, the following is preferable: 



25 



1. 



The Init frame includes a 64-bit transaction identification (Txid) 
field which is assigned by the IVU and is unique for the 
duration of a transaction. 
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2. All i^Dlink data frames and the Ack frame contain an 8-bit 

Txseq/Lane field which is assigned by the RCS and which is 
uniquely associated with both the Txid and lane number of the 
roadside charging station which previously wrote to the IVU. 

5 

The RCS preferably functions as follows with respect to iq^link data 
reception: 

1. Verify correct checksum of all received uplink frames, 

10 

2. Report all verified and unique IVU data frames to the Kryptor 
immediately, 

3. Maintain status of the last n rvUs in an iqjlink IVU buffer 

15 where n is a parameter to be optimized for the application and. 



4. Filter redundant uplink fi^me data and maintain diagnostic 
handshake counts. 

20 The uplink data transfer operates according to the flow chart shown in 

FIGURE 4A- As can be seen, iq^link data frames are first checked to be sure 
that the encoded 4-bit cks is conrect. Frames received in error are sirr^^ly 
ignored Frames received without enror are then checked for a unique 64-bit 
Txid or in the case of Ack/data frames the corresponding 8-bit Txseq/Lane 

25 value. The RCS maintains n uplink IVU buffers where n is optimized for the 
application. Each uplink IVU buffer includes the Txid and provide storage for 
thirty two 128-bit values corresponding to each of the individual IVU frames. 
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The first byte of the word corresponds to the Txseq/Lane fields. The second 
byte corresponds to the t45link Same status byte. The uplink frame status byte 
corresponds to the first byte of an i4)link frame and is conprised of FrNo and 
ValO (for frame 0 only). The third byte of the value contains the handshake 

5 count (i.e,, number of redundant readings for the firame). Assuming that a 
fi^me having a unique Txid is received, the RCS rotates the uplink IVU buffer 
pointers such that the new IVU data buffer overwrites the oldest TVU data 
buffer. The Txid and status are then stored in the buffer, the handshake count 
for the corresponding frame is set to one, and the entire frame is reported to 

10 the Kryptor. It should be noted that only the Txid and status byte need be 
stored by the RCS once the entire fi:ame is reported to the Kryptor. Assuming 
that a new firame is received with a non-unique Txid, the firame status byte is 
stored, the conresponding firame handshake count is set to one, and the entire 
frame is reported Assuming that a non-unique Txid (or TxseqAane number) 

15 and previously received fr^me wdth unique status is received, the new status is 
saved, the corresponding handshake count (HS) is set to one, and the fi^me is 
reported. Assuming that a non-unique Txid and previously received firame 
with non-unique status is received, the corresponding handshake count is 
incremented and the firame is otherwise ignored. Each time a firame is reported 

20 to the Kryptor it is checked to see if the fi-ame is a Nack firame conresponding 
to a pending downlink message request. If so, a downlink message retry is 
initiated once a downlink grant has been receiv^. It should be noted that the 
frame status for a given IVU could change during the course of a single 
transaction. These firames are considered unique and shall be reported to the 

25 Kryptor immediately. It is the responsibility of the IVU to ensure that Udata 
in IVU link ASIC memory is not changed without a corresponding change to 
either the Txid or status byte. These constraints provide for an efficient 
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uniqueness determination within the RCS finnware based ^x)n the first 9 bytes 
of each frame for Init and Nack frames and first 2 bytes of each frame for Ack 
and data frames. 

5 The RCS preferably funaions as follows with resj)ect to downlink data 

transmission: 

- 1. Receive downlink message requests &om Kryptor, 

10 2. Transmit downlink messages to the IVU during downlink grant 

intervals, if enabled, 

3. Verify response fix)m IVU and automatically retry downlink 
transmissions as required, 

15 

4. Retransmit only those firames received in error by the IVU, and 



5. Report result of downlink transaction to Kryptor if a failure 
occurs. 

20- 

The process begins by the Kryptor sending a downlink message request 
to the RCS. The RCS responds by storing the request in the downlink 
message buffer, setting a time-out, and transmitting a command primitive 
followed by a command message to the IVU during downlink grant intervals. 
25 The RCS continually resends the message and attempts to verify that all data 
frames have been successfully received until a preset maximum retry count has 
been exceeded or the downlink message request buffer has been overv\Titten by 
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subsequent downlink message requests whichever happens first. The maximum 
number of downlink message attempts may be set by the Kryptor. If the data 
is successfiilly verified, the RCS may transmit the corresponding Ack/data 
frames to the Kryptor. If the maximum retry count is exceeded prior to 
5 verification of the downlink message, the RCS sends a failed downlink status 
message to the Kryptor. 

The RCS issues a downlink message to the IVU, sets a time-out, and 
waits for a response. The downlink message is buffered internally and remains 
10 pending until one of the following occurs: 

1. The downlink message maximum retry count is exceeded, or 

2. The pending downlink message request is overwritten by a 
15 subsequent request, or 

3. An Ack/Data message is received. 

If no response is received fi-om the P/U v^thin a preset time interval, 
20 the RCS assumes that the message was not received and retransmits the 
message (i.e., time-out ejqjired). 

The rVU will respond with either a Nack message or a change in its 
scroll fiames as implicit acknowledgement upon receiving a downlink message. 
25 If the response is a Nack, then the message was received with errors and the 
RCS will retransmit the message with only those data firames designated by the 
Efeel field as having been received in error. This process continues until the 
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entire message is received without error, the maximum retry count has been 
exceeded or the downlink message is overwritten by a subsequent request In 
the case of the retry count being exceeded, the interrogator will issue a feiled 
downlink status message to the Kiyptor, If an (implicit) acknowledgement is 
5 received, then the previous downlink message was received without error. In 
this case, the RCS will issue a newly received frame to the Kryptor as a matter 
of course. 

Given the general requirement to complete and verify a smart card 
10 (SCybased transaction at vehicles speeds up to 160 km/h (or even up to 300 
km/h), it is preferable to optimize the overall RCS transaction in every way 
possible. A summary of a tvpe road p>ricing transaction is shown below. The 
numbers in parenthesis represent the number of frames which would be 
required for other more demanding road pricing scenarios, 

15 

During the precommit phase, the IVU provides a new 64-bit 
transaction identification code (Txid) for each transaction. All frames 
associated with the commit phase are preloaded into the IVU link ASIC 
inemory as required. Also, the scroll RAM is initialized to scroll out the 
20 required frame(s) for hue commit phase. The number of frames will depend 
iqxDn the application. All of these operations are assumed to occur prior to the 
rVU entering hue microwave communication zone, therefore, time is non- 
critical. 

25 During the commit phase, as a vehicle approaches, the IVU 

automatically transmits and the RCS automatically receives all uplink conmiit 
fi-ames and reports same to the Kryptor. It is assumed that the scrolled fi-ames 
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correspond to all frames required for the commit phase (i.e., 1 to 3 frames). 
Therefore, this phase does not require any action on the part of the IVU. The 
intemjgator and Kryptor should be c^jable of handling several rVLTs in 
parallel given the software linkage between fi:ames (i.e , Txid). Of course, it is 
5 also possible that the toll plaza will employ an approach microwave beacon 
communication to ensure IVU corr^atibility with the upcoming RCS toll plaza 
— e.g,, thus to provide aiiple notice for a driver to pull off the road before 
passing the toll plaza (or to go to an alternate manual toll both) if not 
compatible. 

10 

During a challenge phase, once all commit data has been received, the 
Kryptor computes the challenge message and issues the corresponding 
downlink message request to the RCS. The RCS then transmits the challenge 
message to the IVU. As described elsewhere, the RCS performs the necessary 

15 retries as required until the message is verified The IVU issues a Nack frame 
if incorrect challenge data is received in which case the RCS immediately 
resends the challenge message. Once the IVU receives a correct challenge 
message, it will transmit data frames (i.e., payment data). This message 
informs the RCS that correct challenge data (i.e., correct crc) was received and 

20 there is no need to resend the challenge message. The RCS then reports the 
payment frames to the Kryptor as received. For several reasons, the RCS 
maintains downlink message requests for n IVUs. The value of n may be 
optimized for the s^lication. Downlink message requests are maintained 
within the RCS until the downlink message buffer overflows in v^ch case the 

25 oldest request will be overwritten. The multiple buffering of downlink 
message requests permits: 
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1, interaction with multiple rVLTs simultaneously within the 
read/write range of the RCS. As a rule, the RCS will always attenpt 
to write to the IVU from which it received data most recently and 



5 



2. retry of downlink messages whenever the RCS receives a Nack 



message. 



During the pjayment phase, the IVU issues the payment frames 
following successful receipt of the challenge frame. The payment frames are 

10 transmitted to the Kryptor by the RCS as received The Kryptor uses the 
payment data to confirm that the SC has been correctly debited Since there 
may be numerous payment frames, the RCS shall be required to filter 
redundant frames depending, of course, upon the quality of the microwave link 
and possible interference from nearby XVLTs and RCS's. Since the payment 

15 frames are linked in software through the Txseq/Lane fields, it is possible for 
the RCS to receive fi^mes in discontinuous intervals and still allow for 
reassembly of the corrplete payment message by the Kryptor. As with the 
commit phase, it should be possible for the RCS and Kryptor to handle several 
rVLTs in parallel given the software linkage between fi:ames. The RCS 

20 incorporates a hi^ speed, ftill di^lex synchronous serial interface with the 
Kryptor operating at a data rate of 1.536 MBaud. This data rate is based upon 
the existing 68302 microprocessor clock rate of 15.36 MHz and limitations as 
defined in Appendix A of the Motorola MC68302 User^s Mammal. 

25 The RCS high performance synchronous serial communication 

interface is provided in order to communicate to the real time Kryptor module. 
Messages may be initiated by either the Kryptor or by the RCS link controller. 
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The protocol preferably siq^ports the transfer of 8-bit binary data in order to 
achieve hi^ bandwidth and is of the error correcting type in order to ensure 
reliable operatioa The RCS link controller preferably inplements a priority 
scheme such that messages received at the serial port shall be saved pending 
5 conpledon of ongoing microwave communication tasks. That is to say, that 
microwave tasks have priority over serial communication tasks, but character 
input are handled in parallel with microwave task processing. The Kryptor 
waits for conpletion of one request prior to issuing a second request. 
Generally, the RCS link controller issues messages to the Kryptor in the order 
10 in which they are processed 

The Kryptor may issue a variety of requests to the link controller. 
Requests may include an information field which is con^sed of a command 
code and optional parameters associated with the command code. The format 
15 for the information field is as follows: 

<CmdxData> 
where, 

<Cmd> = Command code (00-FF Hex) 

20 <Data> = Parameter data of variable length 

One possible set of command codes is summarized below: 
Description 

Perform software reset of RCS 
Request RCS firmware version no 
Set configuration to default 



<Codes> 

25 00 
01 
02 
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03 Set configuration and mode 

04 Request configuration 

05 Set date and time 

06 Request date and time 

5 08 Send downlink message to IVU 

09 downlink program code 



The RCS link controller may also issue messages to the Krypton 
Messages may typically include an information field which is comprises of a 
10 command code and optional data associated with the command code. One 
possible fomiat for the infonnation field is as follows: 



<CmdxData> 
where, 

15 <Cmd> = Command code (OO-FF Hex) 

<Data> = Parameter data of variable length 



Currently defined controller to Kryptor messages are listed below: 



20 Code Descrit^on 

00 Transmit data and time 

01 Transmit configuration 

02 Transmit diagnostics 

03 Transmit sign on message 

25 "RCS 1.0 Ver y.yyx(c) 1993" (y is 0-9 and x is A-F) 
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Note: This message is issued upon power up or following the reset 
request The initial firmware release of the link controller is Ver 
l.OOA- If an encoded and calculated memory checksum disagree then 
the version will be reported as Ver Czzx where zz is an error code as 
5 defined below. CoName is the name of conpany holding copyright 



10 



zz Description 

01 Bad program PROM 

02 Bad program EEPROM 

04 Bad configuration EEPROM 



In the case of zz = 01, the RCS must be returned to the factory for 
rqjair. In the case of zz - 02, new firmware must be downloaded and the 
RCS will automatically switch to the Download Mode in anticipation of the 
15 download In the case of zz = 04, the RCS will automatically reset all 
configuration parameter to the factory default state and, therefore, the user 
must reconfigure the RCS as desired. Combination errors are also possible 
(e.g., bad program and confirmation EEPPROM). 

20 A presently preferred embodiment utilizes the following fiame data 

assignments for the pre-commit phase and the following three data 
communication phases shown in Figure 5. 



25 



The three da ta packages involved int eh data communication packages 
for these phases are given in Tables 4 and 6: 
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JABLEA 

5 

(XXVEVHT message 



Description 


Frame 
number 

s 


No. of 
fiames 


Bits 

available 


Bils 
utilized 


% Utilization 


key version 

yj 








16 




card type si 
type 








8 




vehicle 
class sV 








8 




check 
index c 












entrv plaza 
Ep' 








5 




blcxk 0 dc 
axid) 








64 




byte 9 of 
dc 








8 




Total 


1 


1 


112 


112 


100.0 



25 



30 
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CHALLENCa: message 



Description 


Frame 
numbers 


No. of 
fi-ames 


Bits 

available 


Bits 
utilized 


Utilizatio 
n 


spoof 








16 




seq 








4 




lane 








4. 




Subtotal 


command 


0.5 


24 


24 


100.0 


digits oQ 








40 




station Id 
sC 








16 




time 








24 




Total 


0 


1 


88 


80 


90.9 



20 

TABLED 

PAYMENT message 



Description 


Frame 
numbers 


No of 
flames 


Bits 

available 


Bits utilized 


% 

Utilization 


Rest of dc 


4-8 


4 




440 




Wrapped 
W 


8-13 


6 




640 




Opener R 


13 


1 




64 




Total 


4-13 


11 


1144 


1144 


100.0 
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Altbou^ thoudi only one embodiment of this invention has been 
described in detail, those skilled in the art will recognize that many variations 
and modifications of this particular embodiment may be made while yet 
5 retaining one or more of the many novel features and advantages of this 
inventioa For example, many of the IVU and/or RCS circuits could 
advantageously be sinplified and/or fiirther integrated in a commercialized 
embodiment of this invention. Accordingly, aU such variations and 
modifications are intended to be included within the scope of the appended 
10 claims. 
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WHAT TSn AIMED K: 

1. An in- vehicle unit (TVU) for use in an automatic highway toll collection 
system, said IVU comprising: 

an rf antenna having a radiation pattern adapted for disposition in 
proxiniity to an associated vehicle and for communicating with a roadside 
collection station (RCS) while moving therepast; 

rf circuits connected to said antenna for operating in either mode (a) 
wherein a Har^i uplink is established with an RCS by modulating the reflectivity 
of said antenna or mode (b) wherein a data downlink is established with an 
RCS by demodulating received rf signals; 

a smart card controller removably connected with a smart card; and 
a link controller connected to said rf circuits and to said smart card controller 
and including circuits for causing operation in mode (a) to repetitively transmit 
first Hata to an RCS and in mode (b) to receive second data, based at least in 
part on said first d m^, whereupon operation is switched back to mode (a) for 
transmission of third data based at least in part on said second data, said first 
and third Hatn together collectively corr^^rising a cryptographically secured 
electronic money transfer. 

2. An in-vehicle unit (TVU) as in claim 1 wherein said removably 
connected smart card contains cryptographically secured electronic money, said 
smart card and smart card controller being connected to the link controller to 
provide (a) at least a portion of said first data as part of a cryptographically 
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secured electronic check and (b) at least a portion of said third data based in 
part on said second data and the remainder of a cryptographically secured 
electronic check representing a verified valid debit of a hi^way toll from the 
smart card. 

3. An in-vehicle unit (TVU) as in claim 1 wherein said second data 
includes a shortened encrypted version of at least some of said first data and is 
utilized to authenticate the RCS. 

4. An in-vehicle unit (TVU) as in claim 1 wherein said second data 
includes RCS transaction sequence and RCS lane number data. 

5. An in-vehicle unit (TVU) as in claim 1 wherein said second and/or third 
data includes plural frames of data, each frame including the same RCS 
transaction sequence and RCS lane number data 

6. An in-vehicle unit (TVU) as in claim 1 wherein said smart card includes 
pre-stored increments of electronic money that are cryptographically secured 

:;and yet anonymous by failing to include any data capable of revealing person 

vor vehicle identity to the RCS. 

7. An in-vehicle unit (TVU) as tn claim 6 wherein said pre-stored 
increments of electronic money are untraceable electronic checks 
communicated from the IVU to an RCS in a cryptographically sealed 
electronic envelope with opener. 
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8. An in-vehicie unit (TVU) as in claim 1 wherein said first data includes 
unique transaction identification data 

9. An in-vehicle unit (IVU) as in claim 8 wherein said unique transaction 
identification Hata includes a portion of toll payment data which otherwise 
would be transmitted as part of said third data 

10. An In-vehicle unit (IVU) as in claim 1 wherein the smart card is 
adapted to provide with (a) standard-speed smart card functions at a first rate 
when connected to standard smart card interfaces and (b) high-speed smart 
card fimctions at a second rare higher than said first rate when connected to an 
IVU. 

11. An in-vehicle unit (TVU) as in claim 1 wherein said IVU includes 
means for optionally operating in a post-payment mode wherein said first 
and/or third data includes billing identity data sufficient to permit a subsequent 
billing for the toll. 

12. An in-vehicle unit (TVU) as in claim 1 wherein the data processing 
circuits of said IVU include means equable of processing both closed hi^way 
tolls and open hi^way tolls. 

13. An in-vehicle unit (TVU) as in claim 1 including means for initiating 
operation in mode (a) upon detecting TVU proximity to an RCS. 

14. A roadside coUeaion station (RCS) for use in an automatic hi^way 
toll collection system, said RCS comprising: 
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an rf antenna having a radiation pattern ad^ted for disposition in 
proximity to an associated highway lane at a toll collection zone and for 
communicating with an in-vehicie unit (IVU) moving therepast; 

rf circuits connected to said antenna for generating either mode (a) 
wherein a CW rf signal enables an i^jlink communication of data from a 
passing IVU via modulated reflections of the CW rf signal or mode (b) 
^wherein a modulated rf signal provides downlink communication of data to a 
passing IVU; and 

a link controller connected to said rf circuits and including means for 
maintaining said rf circuits in mode (a) until first data is successfully received 
from an IVU and thereafter switching to mode (b) until second data, based at 
least in part on said first data, is transmitted to the IVU in question whereupon 
operation is switched back to mode (a) for receipt of third data, based at least 
in part on said second data, said first and third data together collectively 
comprising a cryptographically secured electronic money transfer. 

ul5. A roadside collection station (RCS) as in claim 14 fiirthef comprising: 
cryptogr^hic ^^^^ processing circuits connected to receive uplink data 
from said controller and to provide downlink data to said controller, said 
cryptographic Hatn processing circuits generating at least a portion of said 
second (\^^^ from said first data and also authenticating said first and third data 
as collectively representing a verified valid debit of a highway toll from a 
smart card containing cryptographically secured electronic money. 
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16. A roadside collection station (RCS) as in claim 14 wherein said second 
includes a shortened encrypted version of at least some of said first data. 

17. A roadside collection station (RCS) as in claim 14 wherein said second 
Hata includes RCS transaction sequence and RCS lane number data. 

18. A roadside collection station (RCS) as in claim 14 wherein said second 
and/or third d^ta includes plural frames of data, each frame including the same 
RCS transaction sequence and RCS lane number data. 

19. A roadside collection station (RCS) as in claim 17 or 18 including data 
processing circuits capable of handling and successfiilly processing data from 
and to a plurality of rVLTs during the same time intemal using said RCS 
transaction sequence and RCS lane number data to correctly associate together 
each rVU toll collection transaction. 

20. A roadside collection station (RCS) as in claim 14 including a 
connection to a network of other RCS units associated with nearby hi^way 
lanes over which network cross-lane read-in of said third data is passed to the 
plaza conputer. 

21. A roadside collection station (RCS) as in claim 14 including a downlink 
control circuit which prevents operation in mode (b) unless authorized by a 
plaza downlink controller connected thereto. 

22. A roadside collection station (RCS) as in claim 21 in combination with 
plural RCS's connected to said downlink controller which prevents 
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simultaneous downlink communications from RCS's associated with adjacent 
hirfiway lanes. 

23. An automatic hidiway toll collection system conprising: 
a roadside collection station (RCS) disposed in proximity to at least one 
^ respectively corresponding hi^way lane and having a bi-directional 

-^electromagnetic communication link coupled to a predetermined toll 
collection zone disposed in proximity to said at least one respectively 
corresponding hidiway lane; 

an in-vehicle unit (IVU) disposed in each of plural vehicles passing 
along the highway and having a bi-directional electromagnetic data 
communication link coupled to a predetermined vehicular communication zone 
that moves with the vehicle and intersects said toll collection zone of the RCS 
for a limited time period as the vehicle passes along said at least one hi^way 
lane; 

said TVLTs each including a smart card capable of containing pre-stored 
increments of electronic money; and 

each said RCS and IVU including respective data processing circuits 
connected to its electromagnetic data communication link for effecting at least 
the following real-time communication and data processing operations during 
said limited time period: 

(a) passing first d^t^ from an IVU to an RCS to initiate payment of a 

toll; 
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(b) calculating toll data at the RCS which is based on said first data and 
passing fix)m the RCS to the IVU second data, including said toll data and 
unique linkage data linking said second data to said first data; and 

(c) debiting the toll fi-om the smart card at the IVU and thereafter 
passing third d a t?^ firm the IVU to the RCS including verification data 
verifying said debiting and unique linkage data linking said third data to said 
first and second data. 

24. An automatic hi^way toll collection system as in claim 23 wherein 
said pre-stored increments of electronic money transferred to the RCS are 
cryptographically secured and yet anonymous by failing to include any data 
enable of revealing person or vehicle identity to the RCS. 

25. An automatic hi^way toll collection system as in claim 23 wherein 
said pre-stored increments of electronic money are untraceable electronic 
checks communicated fix)m the IVU to the RCS in a ciyptographically sealed 
electronic envelope with opener. 

26. An automatic hi^way toll collection system as in claim 23 wiierein 
said first Hata includes unique transaction identification data. 

27. An automatic hi^way toll collection system as in claim 26 wherein 
said unique transaction identification data includes a portion of toll payment 
data which would otherwise be transmitted as part of said third data. 
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28. An axitomatic hidiway toll collection system as in claims 26 or 27 
wherein 

said unique linkage data, comprising part of the second data, includes a 
shortened and encrypted version of said transaction identification data; and 

said rVU includes means for locally creating a similar shortened and 
^ encrypted version of the transaction identification data and for comparing that 
^to the relevant portion of received second data to verify the authenticity of the 
^RCS. 

29. An automatic highway toll collection system as in claim 23 wherein 
said unique linkage data, comprising a portion of the second data and a portion 
of the third data, includes RCS transaction sequence and RCS lane number 

30. An automatic highway toll collection system as in claim 29 wherein 
said second and/or third data includes plural frames of data, each frame 
including said RCS transaction sequence and RCS lane number data. 

_31. An automatic hi^way toll collection system as in claim 23 wherein the 
- .RCS includes means for communicating with and processing data from and to 
a plurality of IVLPs during a single said limited time period using said unique 
linkage Hnta to associate together the data related to each IVU toll collection 
transaction. 

32. An automatic highway toll collection system as in claim 23 having a 
plurality of said RCS's, each RCS being disposed in proximity to a respectively 
associated highway lane at a toll plaza and interconnected to a supervisory 
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plaza conqjuter network to which each RCS forwards received third data not 
linked to its respectively associated hi^way lane, said plaza network including 
means for thereafter verifying the combined parts of a payment at the plaza 
conputer. 

33. An automatic highway toll collection system as in claim 23 having a 
plurality of said RCS's, each RCS being disposed in proximity to a respectively 
associated hi^way lane and interconneaed to a downlink timing controller 
which allows a given RCS to transmit data to an IVU only during downlink 
time periods authorized by the controller. 

34. An automatic highway toll collection system as in claim 33 wtierein the 
downlink timing controller includes means for preventing simultaneous 
downlink communications from RCS*s associated with adjacent highway lanes. 

35. An automatic highway toll collection system as in claim 23 wherein 
each smart card is removably associated with its IVU and is adapted to provide 
both (a) standard-speed smart card fimctions at a first rate when connected to 
standard smart card interface and (b) hi^-speed smart card fimctions at a 
second rate hi^er than said first rate when connected to an IVU. 

36. An automatic highway toll collection system as in claim 23 wherein at 
least some said IVUs include means for optionally operating in a post-payment 
mode when said first and/or third data includes billing identity data sufficient 
to permit a subsequent billing for the toll. 
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37. An automatic highway toll collection system as in claim 23 or 36 
wherein the d af? processing circuits of each said RCS and IVU include means 
enable of processing both closed highway tolls and open highway tolls. 

38. An automatic highway toll collection system as in claim 23 wherein all 
real-time ^^^^ processing is performed in the RCS and IVU. 

-39. An automatic hidiway toll collection system as in claim 23 wherein, 
during said limited time period; 

said RCS initially transmits CW electromagnetic fields into said 
collection zone awaiting the receipt of said first data fi-om an IVU via 
modulated reflections of said fields; and 

said rVUs begin continuously modulating said reflected fields upon 
detecting entry into said collection zone by detecting the presence of said CW 
fields thereby continuously transmitting said first data. 

40. An in-vehicle unit (TVU) for use in an automatic hi^way toll collection 
system, said IVU con^msing: 

Ham communication circuits connected to transmit first data to a 
roadside collection station (RCS) while passing thereby; 
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cryptogr^hic data processing circuits connected to encrypt at least a 
portion of said first data with a cryptosystem key also present in an authentic 
RCS; 

Har;^ communication circuits connected to receive second data from an 

RCS; 

authentication means connected to con5)are at least a portion of said 
second Hqta with an encrypted portion of said first data to communicating 
RCS; and 

toll charging means connected to pay a hidiway toll as requested by 
said RCS only if its authenticity has been successfully ascertained 

41. An in-vehicle unit (T/U) for use in an automatic hidiway toll collection 
system, said IVU comprising: 

Hr^tp communications circuits adapted for (a) sending first data to a 
roadside collection station (RCS) while passing thereby; (b) thereafter receiving 
send data finom said RCS; and (c) still later sending third data to the RCS; 

said third da ta including plural packets of data; and 

said Hata communications circuits including means for including in each 
said packet of data predetermined linkage data uniquely linked to said first and 
second data. 
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42. An in-vehicle unit (TVU) for use in an automatic highway toll collection 
system, said IVU comprising: 

data communications circuits for transceiving data with a roadside 
collection station (RCS) while passing thereby; 

a d^^ta store of cryptographically secured monetary funds; and 

means for sending a portion of the data representing said monetary 
funds in an initial data communication with an RCS to also serve as a unique 
toll collection transaction identity code. 

43. An in-vehicle unit (JVU) for use in an automatic hi^way toll collection 
system, said IVU con^^rising: 

data communications circuits for (a) sending fiist data to a roadside 
collection station (RCS) while passing thereby; (b) thereafter receiving second 
data from said RCS; and (c) still later sending third data to the RCS; and 

means for automatically initiating operation of said data 
communications circuits in mode (a) iqxDn detecting IVU proximity to an RCS. 

44. A roadside collection station (RCS) for use in an automatic hidiway 
toll collection system, said RCS comprising: 
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data communications circuits adapted for (a) receiving first data fiom 
an in-vehicle unit (TVU) moving therepast; (b) thereafter transmitting second 
data to said IVU; and (c) still later receiving third data fi^m said IVU; and 

means for encrypting at least a portion of said first data and for 
including at least some of the result as part of said second data to authenticate 
the RCS to the IVU. 

45, A roadside collection station (RCS) for use in an automatic highway 
toll collection system, said RCS comprising: 

data communications circuits adapted for (a) receiving first data from 
an in-vehicle unit (IVU) moving therepast; (b) thereafter transmitting second 
ij^^t;^ to said rVU; and (c) still later receiving third data fi-om said IVU; and 

means for including in said second data unique linkage data to said first 
H^ta and for detecting and using similar unique linkage data in said third data 
to associate same with the correct IVU and first data even in the presence of 
multiple communicating IVUs within a closely spaced time duration. 

46. A roadside collection station (RCS) for use in an automatic highway 
toll collection system, said RCS comprising: 

dam communications circuits for transceiving data with in-vehicle units 
(TVU) moving therepast in a multi-lane highway environment; and 



wo 95/10147 



76 

said (^^ta communications circuits including control means for 
peraiitting data transmit and receive operations with an IVU to occur only 
when permitted by an external communication timing controller. 
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AMENDED CLAIMS 

[received by the International Bureau on 17 February 1995 (17.02.95); 
original claims 1-46 replaced by amended claims 1-46 (13 pages)] 



1. An in-vehicle unit for use in an automatic highway toll 
collection system, said in-vehicle unit comprising: 

an rf antetma having a radiation pattern disposed in proximity 
to an associated vehicle for communicating with a roadside collection 
station while moving therepast; 

rf circuits connected to said antenna for operating in either a 
first mode wherein a data uplink is established with a roadside 
collection station by modulating the reflectivity of said antenna or a 
second mode wherein a data downlink is established with a roadside 
collection station by demodulating received rf signals; 

a smart card controller connected with a smart card; and 

a link controller connected to said rf circuits and to said smart 
card controller and including circtdts for causing operation in said 
first mode to repetitively transmit first data to a roadside collection 
station and in said second mode to receive second data, based at least 
in part on said first data, whereupon operation is switched back to 
said first mode for transmission of third data based at least in part 
on said second data, said first and third data together collectively 
comprising an encrypted electronic money transfer. 

2. An in-vehicle unit as in claim 1 wherein said smart card 
contains encrypted data representing monetary value, said smart card 
and smart card controller being connected to the link controller to 
provide (a) at least a portion of said first data as part of an encrypted 
data set representing a transfer of monetarj'' value and (b) at least a 
portion of said third data based in part on said second data and the 
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remainder of said encr\^pted data set representing a transfer of 
monetary value and representing a verified valid debit of a highway 
toll from the smart card. 

3. An in-vehicle unit as in claim 1 wherein said second data 
includes an encryption of at least some of said first data and is 
utilized to authenticate the roadside collection station. 

4. An in-vehicle unit as in claim 1 wherein said second data 
includes roadside collection station transaction sequence and roadside 
collection station lane number data. 

5. An in-vehicle xmit as in claim 1 wherein at least one of 
said second and third data includes plural frames of data, each frame 
including the same roadside collection station transaction sequence 
and roadside collection station lane number data. 

6. An in-vehicle tinit as in claim 1 wherein said smart card 
includes encrypted data representing pre-stored increments of money 
that are anonymous by failing to include any data capable of 
revealing person or vehicle identity to the roadside collection station. 

7. An in-vehicle unit as in claim 6 wherein said pre-stored 
encrypted data representing increments of money are untraceable and 
are communicated from the in-vehicle imit to roadside collection 
station in an encrypted form that includes data required for its 
decryption. 

8. An in-vehicle unit as in claim 1 wherein said first data 
includes unique transaction identification data. 
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9. An in-vehicle unit as in claim 8 wherein said unique 
transaction identification data includes a portion of toll payment data 
which otherwise would be transmitted as part of said third data. 

10. An in-vehicle unit as in claim 1 wherein the smart card is 
adapted to provide with standard-speed smart card functions at a 
first rate when connected to standard smart card interfaces and high- 
speed smart card fimctions at a second rate higher than said first 
rate when connected to an in-vehicle unit. 



11. An in-vehicle unit as in claim 1 wherein said in-vehicle 
unit includes means for optionally operating in a post-payment mode 
wherein at least one of said first and third data includes billing 
identity data for a subsequent billing of the toll. 

12. An in-vehicle unit as in claim 1 wherein the data 
processing circuits of said in-vehicle unit include means for processing 
both closed highway tolls and open highway tolls. 

13. An in-vehicle imit as in claim 1 including means for 
initiating operation in said first mode upon detecting in-vehicle unit 
proximity to an roadside collection station. 

14. A roadside collection station for use in an automatic 
highway toll collection system, said roadside collection station 
comprising: 

an rf antenna having a radiation pattern disposed in proximity 
to an associated highway lane at a toll collection zone and for 
communicating with an in-vehicle moving therepast; 
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rf circuits connected to said antenna for generating either a first 
mode wherein a CW rf signal enables an uplink communication of 
data from a passing in-vehicle unit via modulated reflections of the 
CW rf signal or a second mode wherein a modulated rf signal 
provides downlink communication of data to a passing in-vehicle tmit; 
and 

a link controller connected to said rf circuits and including 
means for maintaining said rf circuits in said first mode xmtil first 
... data is successfully received from an in-vehicle unit and thereafter 
switching to said second mode until second data, based at least in 
part on said first data, is transmitted to the in-vehicle unit in 
question whereupon operation is switched back to said first mode for 
receipt of third data, based at least in part on said second data, said 
first and third data together collectively comprising an encrypted 
electronic money transfer. 

15. A roadside collection station as in claim 14 further 
comprising: 

cryptographic data processing circuits connected to receive 
uplink data from said controller and to provide downlink data to said 
controller, said cryptographic data processing circmts generating at 
least a portion of said second data from said first data and also 
authenticating said first and third data as collectively representing a 
verified valid debit of a highway toll from a smart card containing 
encrypted data representing monetary value. 

16. A roadside collection station as in claim 14 wherein said 
second data includes at least some of said first data in encrypted 
form. 
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17. A roadside collection station as in claim 14 wherein said 
second data includes roadside collection station transaction sequence 
and roadside collection station lane number data. 

18. A roadside collection station as in claim 14 wherein said 
second and/or third data includes plural frames of data, each frame 
including the same roadside collection station transaction sequence 
and roadside collection station lane number data. 

19. A roadside collection station as in claim 17 or 18 including 
data processing circuits for handling and processing data from and to 
a plurality of in-vehicle units during the same time internal using 
said roadside collection station transaction sequence and roadside 
collection station lane number data to correctly associate together 
each in-vehicle unit toll collection transaction. 

20. A roadside collection station as in claim 14 including a 
connection to a network of other roadside collection station xmits 
associated with nearby highway lanes over which network cross-lane 
read-in of said third data is passed to the network. 

21. A roadside collection station as in claim 14 including a 
downlink control circuit which prevents operation in said second mode 
unless authorized by an external downlink controller connected 
thereto. 

22. A roadside collection station as in claim 21 in combination 
with plural roadside collection stations connected to said external 
downlink controller which prevents simultaneous downlink 
communications from roadside collection stations associated with 
adjacent highway lanes. 
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23. An automatic highway toll collection system comprising: 

a roadside collection station disposed in proximity to at least one 
respectively corresponding highway lane and having a bi-directional 
electromagnetic data commimication link coupled to a predetermined 
toll collection zone disposed in proximity to said at least one 
respectively corresponding highway lane; 

an in-vehicle unit disposed in each of plural vehicles passing 
along the highway and having a bi-directional electromagnetic data 
communication link coupled to a predetermined vehicular 
communication zone that moves with the vehicle and intersects said 
toll collection zone of the roadside collection station for a limited time 
period as the vehicle passes along said at least one highway lane; 

said in-vehicle units each including a smart card containing 
encrypted data representing pre-stored increments of money; and 

each said roadside collection station and in-vehicle unit including 
respective data processing circuits connected to its electromagnetic 
data communication link for effecting at least the following real-time 
communication and data processing operations during said limited 
time period: 

(a) passing first data from an in-vehicle vmit to a roadside 
collection station to initiate payment of a toll; 

(b) calculating toll data at the roadside collection station which 
is based on said first data and passing from the roadside collection 
station to the in-vehicle unit second data, including said toll data and 
unique linkage data linking said second data to said first data; and 
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(c) debiting the toll from the smart card at the in-vehicle unit 
and thereafter passing third data from the in-vehicle unit to the 
roadside collection station including verification data verifying said 
debiting and unique Unkage data linking said third data to said first 
and second data. 

24. An automatic highway toll collection system as in claim 23 
wherein said data representing pre-stored increments of electronic 
money transferred to the roadside collection station are encrypted and 
yet anonymous by failing to include any data capable of revealing 
person or vehicle identity to the roadside collection station. 

25. An automatic highway toll collection system as in claim 23 
wherein said data representing pre-stored increments of electronic 
money are communicated from the in-vehicle unit to the roadside 
collection station in a encrypted form that includes data required for 
its decryption. 



26. An automatic highway toll collection system as in claim 23 
wherein said first data originating at the in-vehicle unit includes 
unique transaction identification data. 

27. An automatic highway toll collection system as in claim 26 
wherein said imique transaction identification data includes a portion 
of toll payment data, the rest of which is transmitted as part of said 
third data. 

28. An automatic highway toll collection system as in claims 
26 or 27 wherein 
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said unique linkage data, comprising part of the second data, 
includes a portion of said transaction identification data in encrypted 
form; and 

said in-vehicle unit includes means for locally creating a similar 
encryption of part of the transaction identification data and for 
comparing that to the relevant portion of received second data to 
verify the authenticity of the roadside collection station. 

29. An automatic highway toll collection system as in claim 23 
wherein said unique linkage data, comprising a portion of the second 
data and a portion of the third data, includes roadside collection 
station transaction sequence and roadside collection station lane 
number data. 

30. An automatic highway toll collection system as in claim 29 
wherein at least one of said second and third data includes plural 
frames of data, each frame including said roadside collection station 
transaction sequence and roadside collection station lane number 
data. 

31. An automatic highway toll collection system as in claim 23 
wherein the roadside collection station includes means for 
communicating with and processing data from and to a plurality of 
in-vehicle units during a single said limited time period using said 
unique linkage data to associate together the data related to each in- 
vehicle unit toll collection transaction. 

32. An automatic highway toll collection system as in claim 23 
having a plurality of said roadside collection stations, each roadside 
collection station being disposed in proximity to a respectively 
associated highway lane at a toll plaza and interconnected to a 
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supervisoiy plaza computer network to which each roadside collection 
station forwards received third data not linked to its respectively 
associated highway lane, said plaza network including means for 
thereafter verifying the combined parts of a payment. 

33. An automatic highway toll collection system as in claim 23 
having a plurality of said roadside collection stations, each roadside 
collection station being disposed in proximity to a respectively 
associated highway lane and interconnected to a downlink timing 
controller which allows a given roadside collection station to transmit 
data to an in-vehicle unit only during downlink time periods 
authorized by the controller. 

34. An automatic highway toll collection system as in claim 33 
wherein the downlink timing controller includes means for preventing 
simultaneous downlink communications from roadside collection 
stations associated with adjacent highway lanes. 

35. An automatic highway toll collection system as in claim 23 
wherein each smart card is removably associated with its in-vehicle 
unit and provides both (a) standard-speed smari: card functions at a 
first rate when connected to standard smart card interface and (b) 
high-speed smart card functions at a second rate higher than said 
first rate when connected to an in-vehicle unit. 

36. An automatic highway toll collection system as in claim 23 
wherein at least some said in-vehicle units include means for 
optionally operating in a post-payment mode when at least one of 
said first and third data includes bilHng identity data for subsequent 
billing of the toll. 
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37. An automatic highway toll collection system as in claim 23 
or 36 wherein the data processing circuits of each said roadside 
collection station and in-vehicle unit include means capable of 
processing both closed highway tolls and open highway tolls. 

38. An automatic highway toll collection system as in claim 23 
wherein all real-time data processing is performed in the roadside 
collection station and in-vehicle unit, 

39. An automatic highway toll collection system as in claim 23 
wherein, during said limited time period; 

said roadside collection station initially transmits CW 
electromagnetic fields into said collection zone awaiting the receipt of 
said first data from an in-vehicle unit via modulated reflections of 
said fields; and 

said in-vehicle units begin continuously modulating said reflected 
fields upon detecting entry into said collection zone by detecting the 
presence of said CW fields thereby continuously transmitting said 
first data. 

40. An in-vehicle unit for use in an automatic highway toll 
collection system, said in-vehicle unit comprising: 

data communication circuits for transmitting first data to a 
roadside collection station while passing thereby; 

crytographic data processing circuits for enciypting at least a 
portion of said first data with a cry^tosystem key also present in an 
authentic roadside collection station; 
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data communication circuits for receiving second data from a 
roadside collection station; 

authentication means for comparing at least a portion of said 
second data with an encrypted portion of said first data to the 
commtmicating roadside collection station; and 

toll charging means for pajdng a highway toll as requested by 
said roadside collection station only if its authenticity has been 
successfully ascertained. 

41. An in-vehicle unit for use in an automatic highway toll 
collection system having toll account memory means and toll data 
processor means, said in-vehicle unit having toll accoxmt memory 
means and toll data processor means comprising: 

data communications circuits for sending first data to a roadside 
collection station while passing thereby; thereafter receiving second 
data from said roadside collection station; and still later sending third 
data to the roadside collection station; 

saiid third data including plural packets of data; and 

said data communications circuits including means for including 
in each said packet of data predetermined linkage data uniquely 
linked to said first and second data. 

42. An in-vehicle unit for use in an automatic highway toll 
collection system, said in-vehicle unit comprising: 

data commimications circuits for transceiving data with a 
roadside collection station while passing thereby; 
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a data store of encrypted data representing monetary funds; and 

means for sending a portion of the data representing said 
monetary fimds in an initial data communication with a roadside 
collection station to also serve as a unique toll collection transaction 
identity code. 

43. An in-vehicle unit for use in an automatic highway toll 
collection system having toll account memory means and toll data 
processor means, said in-vehicle unit comprising: 

data communications circuits for sending first data to a roadside 
collection station while passing thereby; thereafter receiving second 
data from said roadside collection station; and still later sending third 
data to the roadside collection station; and 

means for automatically initiating operation of said data 
communications circuits in a first mode upon detecting an in-vehicle 
unit passing in proximity to a roadside collection station. 

44. A roadside collection station for use in an automatic 
highway toll collection system having toll account memory means and 
toll data processor means, said roadside collection station comprising: 

data communications circuits adapted for receiving first data 
from an in-vehicle unit moving therepast; thereafter transmitting 
second data to said in-vehicle unit; and still later receiving third data 
from said in-vehicle unit; and 

means for encrypting at least a portion of said first data and for 
including at least some of the result as part of said second data to 
authenticate the roadside collection station to the in-vehicle unit. 
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45. A roadside collection station for use in an automatic 
highway toll collection system having toll account memoiy means and 
toll data processor means, said roadside collection station comprising: 

data communications circuits for receiving first data from an in- 
vehicle UBit moving therepast; thereafter transmitting second data to 
said in-vehicle unit; and still later receiving third data from said in- 
vehicle unit; and 

means for including in said second data unique linkage data to 
said first data and for detecting and using similar unique linkage 
data in said third data to associate same with the correct in-vehicle 
unit and first data even in the presence of multiple communicating 
in-vehicle units within a closely spaced time duration. 

46. A roadside collection station for use in an automatic 
highway toll collection system having toll account memoiy means and 
toll data processor means, said road collection station comprising: 

data communications circuits for transceiving data with in- 
vehicle units moving therepast in a multi-lane highway environment; 
and 

said data communications circuits including control means for 
causing data transmit and receive operations with an in-vehicle unit 
to occur only when permitted by an external communication timing 
controller. 
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STATEMENT UNDER ARTICLE 19 



In response to the PCT/ISA/220 Notification of Transmittal of the 
International Search Report dated 22 December 1994, please amend the above- 
identified application by substituting the attached new claims 1-46 (pages 63-75) 
for the originally filed claims. 
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